主流开源协议比较
2012-05-11 14:55:39 
阿炯
在2017年4月，Linux 基金会发布新资源以帮助理解和正确使用开源协议。
刚接触开源软件的新手可能会因为诸多不同的开源协议(许可证)而感到费解，不知道到底要如何使用这些项目。比如， opensource 上列出了9个“流行的许可证”，维基百科上也有长长的一个许可证列表，里面又涉及到分发、修改、专利授权、私人使用、再授权和商业授权等等，很容易让人迷惑。
为了帮助新手掌握这些 FOSS (free and open source software)许可证，Linux 基金会和自由软件基金会 (FSFE)刚刚发布了新的资源来帮助理解和合规使用。
新资源包括：
一本新的、免费的在线书籍, "Practical GPL Compliance: A guide for startups, small businesses, and engineers" 由 Armijn Hemel、MSc 和 Shane Coughlan 编写。该书适用于消费电子、无人机、IoT 或基于通用的 Linux 或基于 Android 汽车设备，旨在提供实用的信息，以快速解决常见问题和错误，并合规授权工程师或团队尽可能高效地完成工作。该书提供简单说明，并提供了清单和可视化流程图。
由 Linux 基金会提供的"cregit" 工具，旨在探讨源码如何随着时间的推移而演变。其主要应用之一是创建一个 token-based 源码视图，将代码解构成编译器识别的最小可解析单元。
FOSSology 3.1 版本是根据 GPL 许可的工具，旨在帮助工程师了解与指定项目相关的 FOSS 许可证。
相关人士还表示，“GPLv2 是促成 Linux 和许多其他 FOSS 项目成功的关键许可证，更好地了解产品中 GPL 许可代码的位置以及如何遵守条款的指南，可以更好地促使 FOSS 生态符合 GPL 许可”。
如何避免开源陷阱
原文：How to Avoid Open Source Traps
作者：CBR工作人员，编译：御坂弟弟
开源许可证的限制性有多大？二进制文件是否可以不需要订阅？有哪些插件可以使用？那些小小的文字中是否隐藏着陷阱？
显而易见的是，开源软件是当下开发和基础设施的默认选择。数据库专家 Percona 公司的首席执行官兼联合创始人 Peter Zaitsev 写道："你会看到无论在编程语言、操作系统、现代数据库技术或整个云原生领域，开源解决方案都是领先的选择之一。由于开源有这样的主导地位，我们经常会看到一些公司将他们的软件营销为 "开源"，尽管它并没有提供真正开源软件所提供的所有（或任何）好处。在这篇文章中，我们看看一些常见的陷阱，并提供如何避免这些陷阱的建议。
什么是开源软件
很多人并没有意识到 "开源 "这个词是没有商标的，所以理论上任何公司都可以用这个词来描述任何一种软件。唯一的后遗症是有可能受到媒体和用户的反对，但其一般不会采取法律行动。如果你关注开源（和自由软件）社区，就会知道有三个不同的组织提供了定义：
Open Source Software (OSI)
Free Software (GNU)
Debian Free Software Guidelines (Debian)
虽然每个组织都使用不同的术语 —— 自由与开源，在精神上略有不同，但对于我们的目的来说，它们是足够相似的。
1)、一些企业领导希望在他们的公司中采用开源软件，并且会关注开源软件是否真的能达到他们的目的。一般来说，他们的目的是（出乎意料）降低成本、提高效率等。首先，他们应该问自己（或计划合作的供应商）以下问题：
2)、许可证 —— 软件的许可证是否适合软件的预期用途？具体来说，当你计划在不同的，或专有的许可证下重新发布合并的作品时，CopyLeft 许可证可能不适合。
3)、如果您停止商业关系，会发生什么？ 如果您与支持或开发您的软件的供应商建立了商业关系，如果您不得不终止这种关系，会发生什么？您想问这个问题是为了避免在价格谈判中被 "挟持"，同时也是因为您的供应商可能会因为业务变化或收购而停止支持您所选择的软件。
4)、有哪些替代品存在？如果软件是真正的开源软件，你至少可以选择在内部继续开发和支持。不过在现实中，这对许多组织来说不切实际，所以有其他的替代方案更好，例如有多个供应商的丰富生态系统。
5)、你能做出贡献吗？ 如果你需要改进软件以更好地满足你的需求，例如硬件支持或特定的软件集成，你希望了解如何实现它。有些软件提供了很大的扩展可能性或贡献者计划，有些则没有。
开源陷阱
现在让我们看看 "开源 "可以用来描述不完全符合上述开源软件原则的软件的不同方式。
“开源兼容”软件（“Open Source Compatible” Software）
现在很多软件都说自己是 "开源兼容"，但并没有宣称自己是开源的。例如，Amazon RDS Aurora 声称与 MySQL 或 PostgreSQL 兼容，但当然，它不是开源的。
当你听到与开源有关的 "兼容 "时，通常意味着从开源解决方案迁移到这种专有技术是很容易的，反之则很难。
当你看到供应商在云端部署的开源软件时，即使 "核心引擎 "与开源版本完全相同，没有任何变化，但周围的管理界面通常是专有的。这意味着，你的团队可能会在运营中开始强烈依赖它。
避免陷阱。 但同时也要知道，有很多优秀的开源兼容软件，它们可以提供比单独的开源软件更好的性能或可用性。
只要你明白这是专有软件，而且你对此无所谓，就没有问题。然而，如果你想利用这种 "兼容性"，并确保你可以用完全开源的软件替代，你需要在应用程序中进行测试。
例如，如果你希望你的应用程序能够运行在 PostgreSQL 上，或者 Azure Database for PostgreSQL 上，除了测试 Amazon RDS Aurora 和 PostgreSQL 的 兼容性之外，你还需要测试功能、性能和管理能力。
开放核心（Open Core）
开放核心软件是指当产品有一个开源版本，通常称为 "社区版"，同时也有一个具有附加功能的专有产品版本，通常称为 "企业版"。社区版或多或少弱于企业版，以确保企业版能够成功销售。
开放核心软件往往以开源软件的名义进行销售。例如，MySQL 自称是 "世界上最受欢迎的开源数据库"，而不是 "世界上最受欢迎的开放核心数据库！"
企业版软件往往包括一些扩展和改进，根据你的情况，这些扩展和改进可能值得拥有。然而，"企业版 "软件类似于 "开源兼容 "软件。" 即，如果你的目标是避免软件锁定，你需要测试你是否真的实现了这一点。
避免陷阱：最简单的方法是避免企业版，如果可以的话，坚持使用社区版。
你应该探索第三方解决方案的生态系统，否则这些解决方案提供的功能只存在于企业版中。如果你面对的是流行的软件，替代品很可能存在。
以 MySQL 为例，Percona Server for MySQL 包括许多企业版功能的替代品，并且是 100% 免费和开源的。不过 Percona 并不是唯一一家提供替代品的公司。如果你正在寻找一个企业审计插件的替代品，你可以看看开源的 McAfee Audit Plugin for MySQL。即使你不能从开源软件中获得你所需要的所有功能，解耦和使用替代供应商往往可以降低你的成本，减少锁定。
源码可用（Source Available）
"源码可用" 是一类许可证，它允许你访问源代码，但与真正的开源软件相比有一些限制。近年来，许多开源软件厂商都选择了源码可用许可证，以保护他们的业务不受大型公有云的干扰。
MongoDB 可能是最著名的，他们将自己的许可证从 AGPL 改为服务器端公共许可证（SSPL），这并不是公认的开源许可证。 此后，Elastic、Confluent(Kafka) 和 Redis 实验室也纷纷跟进，将其部分软件的许可证从开源改为源码可用。
值得注意的是，源码可用类许可证的范围非常广泛。它们中的一些相比开源许可证可能只少一点自由，也有一些可能只提供了审查源代码的权利。
更多情况下，"源码可用" 许可证的设计是为了限制竞争。这可能对开源厂商有利，但它增加了你被锁定的机会。例如，如果正在寻找 MySQL 或 PostgreSQL 的 DBaaS 部署，有来自大大小小的供应商的很多选择。不过如果看看 MongoDB，MongoDB Atlas（MongoDB 提供 的DBaaS）几乎没有替代品。即使存在替代品，也需要云供应商与 MongoDB 公司有授权关系。这与微软 SQL Server 或 Oracle 在各种云上提供的方式并无二致。
除了云的限制外，"源码可用" 许可证可能会限制你选择你喜欢的供应商来帮助你操作或定制这些软件。
避免陷阱：正确设定期望值。”源码可用” 许可证是一种专有许可证，因此你需要仔细审查它，以避免陷入麻烦。
开源，最终（Open Source, Eventually）
"开源，最终" 是一类源代码可用许可证，它的属性是代码在一段时间后成为开放源代码。MariaDB 公司在其部分产品中使用的 BSL（Business Source License）最为著名。
供应商在 BSL 许可证下发布软件时，声称这是一个比开放核心更好的选择，因为随着时间的推移，它的功能会进入开放源码版本。但实际上，只有过时的功能才会开源。而且这通常是没有维护的，并且包含已知的安全漏洞，因此，并不适用于严肃的使用。
另一方面，使用开放核心模式，你通常会得到一套较小的功能，但这些功能往往是安全和维护良好的，因为其目的是吸引用户购买企业版。
避免陷阱：与其他专有软件许可证一样，确保你完全理解你将要使用的东西。
只有源码 "开源"（Source Only “Open Source”）。
因为 "开源 "在技术上适用于程序的源码，而不是二进制文件、支持文档，甚至是完整的构建脚本和环境配置，所以你在这里也会掉进一个陷阱。
在构建上的差异化在开源社区中是相当可以接受的 —— 事实上，开源生态系统泰斗之一 —— RedHat，将认证构建的可用性和及时更新作为其订阅产品的核心，尽管源代码对每个人都是可用的。
避免陷阱：即使软件是开源的，也不要认为它对非客户来说很容易安装和维护。对于流行的软件，可能会有第三方构建和替代品。例如，CentOS 大多可以看作是 RedHat Linux 的替代构建，其二进制文件无需订阅即可使用。
开源许可证的选择
原文：Open source licenses: What, which, and why
作者：JIM SALTER，编译：御坂弟弟
大多数人现在至少听说过开源软件，甚至与其关系密切。同时，开源软件的知名人士对它的名称争论不休，从免费软件到自由软件，再到开源软件，以及上述各种可能的组合。但有一点是每个专家都同意的，那就是如果它没有明确的许可证，它就不是开源软件（或其他什么）。不能在没有许可证的情况下公开一堆源代码，然后说"无论如何，它已经放在那了，任何人都可以得到它"。在世界上大多数国家的版权法的运作方式中，没有明确声明许可证的免费提供的代码，其版权是作者的，作者保留所有权利。这意味着使用未经授权的代码是不安全的，无论是否出版。如果你开始使用它，没有什么可以阻止作者来找你并起诉版权费。
唯一能让你的代码真正成为开源和自由使用的方法就是给它附加一个许可证。最好的办法是在每个文件的头部加上一个注释，写上一个著名的许可证的名称和版本，并在项目的根目录下附上一份完整的许可证副本，命名为 LICENSE 或 LICENSE.TXT。当然，这就引出了一个问题，即使用哪种许可证，为什么？
有几种通用的许可证类型，本文将在各自的章节中介绍它们，并举出这种许可证类型的一个或多个突出的例子。
默认许可 —— 专有，保留所有权利
在大多数司法管辖区，除非另有说明，否则任何代码或内容都自动由作者拥有版权，并保留所有权利。虽然在代码或文档的标题中声明作者和版权日期是一个好习惯，但没有这样做并不意味着作者的权利是无效的。
如果作者在自己的网站、Github仓库等地方提供内容或代码，无论是没有声明许可还是有明确的版权声明，都会保留该代码的使用权和分发权，即使它很容易被查看或下载。如果你在自己的电脑上执行该代码，你就侵犯了作者的使用权，他们可能会以侵犯其版权为由对你提起民事诉讼，因为他们从未授予你该权利。同样，如果复制了该代码，并把它送给朋友，在其他网站上发布、出售或以其他方式在作者最初发布代码的地方以外的任何地方提供，你已经侵犯了作者的发行权，他们有资格对你提起民事诉讼。
请注意，对代码库拥有所有权的作者可以单独授予个人或组织使用该代码的许可。从技术上讲，你永远不会 "购买 "软件，即使它被装在实体中。你实际上购买的是使用软件的许可证 —— 可能包括也可能不包括包含代码副本的物理媒体。
自制的许可证
对于自制许可证的建议，一言以蔽之：不要这样做。
世界上已经有足够多的、被 OSI 认可的开源许可证，几乎所有的人或项目都能找到合适的许可证。编写自己的许可证意味着你的项目、内容或代码的潜在用户将不得不从头开始阅读和理解一个新的许可证。新的许可证将没有经过法庭测试，而许多（虽然不是所有）OSI 批准的开源许可证都经过了测试。更重要的是，你的新许可证将不会被广泛理解。
当一个人或公司想使用一个以 GPL v3、Apache 2.0 或 CC0 为授权的项目时，要弄清楚有关许可证是否以正确的方式授予了足够的权利是相对容易的。向有能力的知识产权律师寻求建议既便宜又方便，因为有能力的知识产权律师应该已经熟悉这些许可证、涉及这些许可证的案例法等等。
相比之下，如果你的项目被授权为 "Joe's Open Source License v1.01"，没有人知道这意味着什么。为使用该许可证的项目提供法律咨询的费用会高得多，而且也很危险，因为知识产权律师需要将许可证的文本评估为一个全新的作品，未经证实和测试。新的许可证可能有不明确的文本、条款之间的无意冲突或者由于作者不理解的法律问题而无法执行。
如果没有选择 OSI 认可的许可证，也会使项目失去某些权利或授权。例如，Google 和 IBM 都向开源项目使用其专利组合的部分内容时提供免版税，而你的项目，无论你认为它有多"自由"，都可能不符合授权的条件。(IBM 特别将 OSI 许可证的批准列为授予条件。)
OSI 批准的许可证
OSI（Open Source Initiative）维护着一份经批准的开源许可证清单，这些许可证符合 OSI 对 "开放源码 "的定义。用 OSI 自己的话说，这些许可证"允许自由使用、修改和共享软件"。这些许可证之间有很多重叠，其中许多可能根本就不应该存在。但在某种意义上，它们中的每一个都获得了足够的推动来通过 OSI 许可证的审批程序。
下文将把这个许可证列表分为三类，并列出每一类中一些比较著名的例子。大多数作者不需要阅读和理解 OSI 的整个列表，通常一个通用许可证类型的常见和不常见的变体之间没有太大差异，因此不值得放弃最常用和最容易理解的版本。
强版权许可
Copyleft 许可证是一种允许自由使用、修改和重新发布所涵盖的知识产权的许可证，但前提是原始许可证保持不变，包括原始项目和任何人可能对原始项目进行的任何修改。这种类型的许可证有时被不屑一顾地或害怕地称为 "病毒式" 许可证：就是附加在 Linux 内核、GNU C 编译器和 WordPress 内容管理系统等著名项目上的许可证。
Copyleft 许可证可以是 "强 "或 "弱 "的：强的 Copyleft 许可证涵盖了项目本身和链接到项目中的任何代码。而弱拷贝许可只覆盖原始项目本身，并允许非拷贝许可的代码甚至是专有代码链接到弱拷贝许可项目中的功能而不违反其许可。
一些比较流行的强版权许可证包括：
GPLv2 —— GNU 通用公共许可证允许自由使用、修改和发布所覆盖的代码，但原始许可证必须保持完整，并涵盖原始项目和任何修改。在 GPLv2 中，不需要归属或专利授权，但第七部分指出，如果专利或任何其他原因会使重新分发的代码对接受者无法使用，禁止重新分发 GPLv2 授权的代码。GPL 还要求任何分发项目编译版本的人也要提供原始的源代码，或者是在分发对象代码的同时提供源代码，或者是按要求提供源代码。
GPLv3 —— GNU 通用公共许可证的第三版在大部分意图和目的上与 GPLv2 类似。然而，它对专利的处理方式有所不同。如果在 GPLv2 下重新发布作品可能需要支付专利费，则 GPLv2 禁止这样做。GPLv3 更进一步，明确授予项目贡献者在当时或将来拥有的任何专利的免费使用权。GPLv3 还明确授予接受者破解任何DRM（数字版权管理）代码的权利，防止他们被指控违反《数字千年版权法（Digital Millennium Copyright Act）》或类似的 "防篡改 "法律。
AGPL —— Affero GNU 通用公共许可证实际上是 GPLv3，但增加了一个重要的附加条款：除了为那些收到 AGPL 授权软件副本的人提供 GPL 自由之外，它还为那些在网络上与 AGPL 授权软件交互的用户提供同样的自由。这就防止了个人或公司对一个打算在网络上广泛使用的项目进行重大的有价值的修改，并拒绝将这些修改免费提供。
因为要向一个对 copyleft 还不是很熟悉的人解释 AGPL 的影响有点困难，下面将多用些笔墨。为了更好地理解它的影响，本文将例举一个真实的 AGPL 授权项目和一个涉及到可能希望采用它的大公司的虚构场景。
基于网络的文件共享套件 Nextcloud 是一个 AGPL 授权的项目。由于它采用 GPL 变体授权，任何个人或公司都可以自由地下载、安装和使用它，无论是为自己还是为他人提供服务（包括付费服务）。假如有一个公司，PB LLC，决定建立一个大型商业网站 Plopbox，以提供对托管 Nextcloud 实例的付费访问。
在使 Plopbox 扩展到数百万用户的过程中，PB LLC 对代码进行了大量修改。修改后的代码消耗的服务器资源要少得多，而且还增加了一些功能，Plopbox 的用户认为这些功能很有价值，足以让 Plopbox 与 Nextcloud 的普通安装有实质性的区别。如果 PB LLC 为了创建 Plopbox 服务而使用的开源项目 Nextcloud 已经获得 GPL 授权，这些修改可以保持专有性，PB LLC 也不会被要求向任何人提供这些修改。
这是因为标准 GPL 的限制只有在重新发布时才会生效，而 PB LLC 并没有重新发布 Nextcloud 的修改版本。由于 PB LLC 只在自己的服务器上安装了 Nextcloud，所以它没有义务自动或按要求向任何人提供 Nextcloud 的副本，无论是原始版本还是修改版本。
然而，Nextcloud 并不是在 GPL 的任何一个标准版本下获得许可的，它是在 Affero GPL 下获得许可的，而 Affero GPL 将 GPL 的所有相关权利授予项目覆盖的网络用户，而不仅仅是代码的接收者。因此，PB LLC 实际上需要以源代码的形式（和对象代码的形式，如果适用的话）向任何使用过该项目（例如，通过开一个 Plopbox 账户）并要求拷贝的人提供他们的可扩展性和新功能的修改。
弱版权许可
弱版权许可证与强版权许可证本质上是相似的，但它并不将其 "病毒式" 保护延伸到链接边界上。对弱版权许可库（或其他项目）本身的修改必须保留原始许可，但该项目之外的任何代码，甚至是完全专有的代码，可以直接链接到弱版权许可项目中的函数。弱版权许可证的数量相对较少。最常遇到的是：
LGPL —— Lesser GNU 通用公共许可证。有时仍然用它的原名 GNU "Library" 通用公共许可证来称呼，因为它最常用于共享库中。与 GPL 许可的项目兼容使用。
MPL 2.0 —— Mozilla Public License。MPL 2.0 与 GPL 许可的项目兼容，之前的版本不兼容。
CDDL v1.0 —— Common Development and Distribution License，最初由 Sun Microsystems 撰写。CDDL 被认为与 GPL 不兼容，尽管这种不兼容性还没有在法庭上得到检验。
LGPL 和 MPL 之间的主要区别是归属。为了从一个不符合 GPL 的项目链接到一个 LGPL 项目，你必须 "给出明显的通知，。。。该库在其中使用（并）受本许可证的保护"。MPL 没有任何归属要求：你可以重新发布 MPL 项目，并链接到 MPL 项目中的函数，而不需要宣布你正在这样做。
Mozilla 公共许可证还以提供 "前向迁移 "而著称。Mozilla 基金会作为许可证的管理者，可能会在未来创建 MPL 的更新版本，并提供唯一的版本号。如果它这样做，任何获得 MPL 2.0 许可的项目用户都可以选择在原来的 MPL 2.0 或任何更新版本的许可下使用它。
CDDL 同样允许向前迁移，但将许可证管理人定义为 Sun Microsystems 而不是 Mozilla 基金会。与 LGPL 和 MPL 2.0 不同，CDDL 通常被认为与 GPL 不兼容。可能是故意的。一些组织还是选择动态链接 CDDL 和 GPL 授权代码，最明显的是 Ubuntu Linux 发行版的制造商 Canonical，他们在 2016 年初通过发行 ZFS 文件系统的 Linux 移植版宣布了他们这样做的决定。
对 Canonical 的立场有一个重要的异议来自 SFC（Software Freedom Conservancy，软件自由保护协会），该协会指出，将 CDDL 和 GPL 代码联系起来必然是违反 GPL 的行为。虽然 SFC 毫不含糊地指出了这一点，但它对 Canonical 的目标表示了 "同情"，其结论的重点是要求 Oracle（CDDL 的许可证管理人，作为Sun Microsystems 的现任所有者）解决这个问题。
如果甲骨文公司在 GPLv2 兼容的许可证下提供原始的 ZFS 代码库，包括任何兼容的允许性许可证，那么这种可用性将反过来使后来的 OpenZFS 项目成为 ”祖父”，而不需要费力地咨询每个贡献者。
我们不建议现代使用 CDDL 许可证，由于它与 GPL 不兼容，它既不能作为一个允许性许可证使用，也不可能作为一个 "GPL 毒药 "使用，因为 Canonical 和其他公司采取了强硬的立场，认为对 CDDL 和 GPLv2 代码的链接的法律挑战会在法庭上失败。
允许性许可证
允许性许可证对所涵盖的项目的使用、分发或修改作出极少的限制。因此，一个允许性许可证往往与另一个允许性许可证非常相似。允许性许可证中最常见的限制是归属。换句话说，这些许可证通常要求在任何衍生的项目中注明原项目的名字。
著名的允许性许可证包括：
BSD 四条款许可证 —— 1990 年最初的 Berkeley 软件发行许可证允许自由使用、修改、再发行，甚至对所覆盖的软件进行再许可。四个条款唯一的限制是：任何再分发必须包括原始项目的版权声明（条款一和条款二），该项目或任何衍生项目的任何广告材料必须承认使用源项目（条款三），以及不授予使用原始项目的作者或所有者的名称来认可任何衍生项目的权利（条款四）。
BSD 三条款许可证 —— 1999 年首次发布的 BSD 三条款许可证省略了原来 BSD 四条款许可证中的广告条款。在其他方面是相同的。
BSD 双条款许可证 —— 也被称为 "简化 BSD 许可证" 或 "FreeBSD 许可证"，BSD 双条款许可证省略了原始 BSD 许可证中的背书条款和广告条款。
Apache 许可证 2.0 —— Apache 许可证是一个与 BSD 双条款许可证类似的允许性许可证，只是它额外授予了类似 GPLv3 的专利权。Apache 2.0 许可证还要求重新发布源项目中存在的 NOTICE 文件的原始内容。如果需要的话，NOTICE 文件可以添加新内容，但不能遗漏原始内容，也不能改变，或者看起来是改变许可证条款。
MIT 许可证 —— 它很模糊，可能指的是几种许可证变体中的任何一种。当有人说 "MIT 许可证" 时，他们通常指的是被称为 "Expat 许可证" 的变体。它与 BSD 双条款许可证类似，授予使用、修改、再分配和再许可的权利，只要求保留并包含原始版权声明。为了消除 "MIT 许可证" 这个术语的用法，OSI 发布了 Expat 许可证的逐字拷贝。
GNU All-permissive 许可证 —— 这是另一个极其简单的允许性许可证，允许使用、重新分发和修改被覆盖的项目，只需要包含原始版权和 GNU All-permissive 许可证本身的单段内容。虽然可以在 GNU APL 下对整个项目进行授权，但这并不常见，也不鼓励这样做。它的真正目的是用于 README、INSTALL 和类似的简单单文件。
虽然 Github 和 Black Duck Software 进行的软件调查都将 MIT 许可证列为最常遇到的开源许可证，但由于其中涉及到的模糊性，因此强烈建议不要使用它。MIT 许可证在授予（或限制）使用方面与 BSD 双条款许可证并无显著不同。
由于 BSD 双条款许可证在其本身的文本和 "BSD双条款许可证" 在正常使用中的含义都相当明确，因此强烈建议使用它。那些希望明确授予专利权的人建议使用 Apache 2.0 许可证，但要注意的是，这使得 Apache 2.0 与 GPLv3 兼容，但与使用更广泛的 GPLv2 不兼容。
公共领域等效许可证
许多人在发布作品时根本没有任何许可通知，只是不想费心阅读或理解任何许可或其含义，并错误地认为提供作品而不提供许可就可以使其 "自由"。人们不需要考虑许可证的愿望可以理解，但恳请这些人使用公共领域的等效许可证来代替。OSI 批准的公有领域等效许可证只有一个，这里有它自己的单项列表：
BSD 0 条款许可证 —— 这是原始 BSD 许可证中的免责声明，没有任何限制性的条款，并且有前面的声明 "允许使用、复制、修改和分发本软件用于任何目的，无论是否收费"。BSD 0 条款许可证并没有特别授予任何接受或使用 BSD 0 条款许可项目的人免版税使用软件专利。这是唯一经 OSI 批准的公有领域等效许可证。
非 OSI 批准的许可证
在大多数情况下，如果一个许可证不是 OSI 批准的，你就不应该考虑使用它。至少应该谨慎使用它。无论你是在寻找强复制许可、弱复制许可还是允许性许可，OSI 批准的列表中都有很多例子，因此，没有理由另寻他法。
另一方面，OSI 批准的公有领域等效许可证只有一个，而那种觉得允许性许可证不够宽容的人往往是非常顽固的，甚至可能会因此而退缩。考虑到这一点，下面将介绍几种最著名的非 OSI 批准的公有领域等效许可证。
Unlicense —— Unlicense 规定，被覆盖的作品将被发布到公共领域，并继续说明这到底是什么意思。这不是 OSI 批准的许可证，部分原因是它使用了 "公有领域" 这个术语，这可能会使任何涉及放在 Unlicense 下的作品的法律情况复杂化。
CC0 —— 创意共享零授权是创意共享系列授权中最宽松的形式，它更常用于涵盖文本和媒体创作，而不是代码。创意共享基金会向 OSI 提交了 CC0，要求批准它成为一个开发源码许可证；虽然 OSI 从来沒有正式拒绝它，但他也无法得出结论来批准它。主要原因是它明确地放弃了专利权的转移，OSI 称这是开源许可证中 "极为罕见" 和 "潜在危险" 的。
WTFPL —— WTF Public License 的缩写，WTFPL 是一个非常简短和非常非正式的申明，你可以用 WTFPL 下的任何代码做任何你想做的事情。自由软件基金会承认 WTFPL 是一个与 GPL 兼容的自由软件许可证，但并不推荐使用它；OSI 完全拒绝了 WTFPL，理由是它 "与公有领域的奉献没有区别"，尽管它没有使用 "公有领域" 这个术语，而且在不同的司法管辖区与公有领域相关的权利也不同。
再次指出，不建议使用任何未经 OSI 批准的许可证。使用任何这些未经批准的公有领域等效许可证无论表面上多么自由，都是一个危险的行为。使用未经 OSI 批准的许可证比不使用任何许可证要好，但这样做有可能使你自己或你的用户失去获得专利甚至金钱资助的资格。
商用友好的开源协议一览
先举两个例子，这两种应该是最常用的许可证了：
MIT许可证：只为作者保留版权，而无任何其他了限制。它使人们几乎可以对您的项目进行任何操作，即时是制作和分发封闭源代码版本。Babel，.NET Core和 Rails 使用MIT许可证。
GNU GPLv3：让人们可以做几乎任何他们想要做的项目，不能分发封闭源代码的版本。Ansible， Bash和 GIMP 使用GNU GPLv3。
如果是在为开源社区做项目，使用社区常用的许可证就可以了，如果希望商用则特别要注意下许可的范围。
Apache License 2.0 ：商业软件最爱，主要条件是要求保留原始版权和许可声明。同时向贡献者明确授予专利权。使用者可以自由修改，进行商业使用，大型项目可以不同的条款分发，没有开源要求，修改源代码需要记录变更。
要点：Apache Licence是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售，但要保留原有的license。
BSD 3-Clause "New" or "Revised" license：允许商业发布和销售。使用者可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。主要条件是要求尊重代码作者的著作权，即包含原始版权和免责声明(二进制形式分发必须分发文档中包含版权申明及免责声明)，且未经事先特别书面许可，不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广。
BSD 2-Clause "Simplified" or "FreeBSD" license：比3-Clause少一个条目，去掉了“不可以用开源代码的“作者/机构的名字”或“原来产品的名字”做市场推广”。
要点：商业软件可以使用，也可以修改使用BSD协议的代码。
GNU General Public License: 商业软件绕开，GPL不允许修改后和衍生的代码做为闭源的商业软件发布和销售。
要点：商业软件不能使用GPL协议的代码。
GNU Library or "Lesser" General Public License (LGPL)：允许商业软件代码动态link到LGPL类库。注意：不可以静态链接，否则你的代码也必须用LGPL协议开源(即：商业软件可以动态使用，但不能修改)。
要点：商业软件可以使用，但不能修改LGPL协议的代码。
Mozilla Public License 2.0：修改的版本需要保持原始版权申明。编译版本需和可获得MPL协议下的源码，修改源代码需要记录变更。
要点：商业软件可以使用，也可以修改MPL协议的代码，但修改后的代码版权归软件的发起者。
Common Development and Distribution License：商业软件可用，也可以修改。可以自行发布许可，允许公共版权使用，提供专利保护，无专利费。
要点：商业软件可以使用，也可以修改CDDL协议的代码。
Eclipse Public License version 2.0：商业软件可用，也可以修改，无需开源。不过将本程序包含在商业产品中的贡献者需要承担因代码而产生的侵权责任，及对所有其他贡献者的相关损失。
要点：商业软件可以使用，也可以修改EPL协议的代码，但要承担代码产生的侵权责任。
Massachusetts Institute of Technology(MIT Or X11 license)
与三条款BSD许可证(3-clause BSD license)内容颇为近似，但是赋予软体被授权人更大的权利与更少的限制。
要点：商业软件可以使用，也可以修改MIT协议的代码，甚至可以出售MIT协议的代码。
一般开源许可证中会说明以下权限、使用条件和责任限制：
商业使用(Commercial use)：该软件及其衍生产品可用于商业目的。
分发(Distribution)：该软件可以被分发。
修改(Modification)：该软件可能会被修改。
专利使用(Patent use)：该许可证提供了明确的专利权授予。该许可明确声明它不授予贡献者专利的任何权利。
私人使用(Private use)：该软件可以私下使用和修改。
开源(Disclose source)：分发软件时必须开源。
许可及版权声明(License and copyright notice)：该软件必须随附许可证和版权声明的副本。
分布式网络使用(Network use is distribution)：通过网络与软件进行交互的用户被授予接收源代码副本的权利。
相同许可证(Same license)：分发软件时，必须以相同的许可证发布修改。在某些情况下，可以使用类似或相关的许可证
状态变更(State changes)：对代码所做的更改必须记录。
责任限制(Liability)：该许可包括责任限制。
商标使用(Trademark use)：该许可证明确声明它不授予商标权，即使没有此类声明的许可证可能不授予任何隐含的商标权。
保证(Warranty)：许可证明确声明不提供任何保证。
另外还有一些属于非软件许可证：
数据，媒体等内容：CC0-1.0，CC-BY-4.0和CC-BY-SA-4.0是开放许可证，用于从数据集到视频的非软件内容。这里CC-BY-4.0和CC-BY-SA-4.0 不应用于软件产品。
文献资料：任何开源软件许可证或媒体开放许可证也适用于软件文献资料。如果您为软件及其文档使用不同的许可证，请确保指定文档中的源代码示例也已获得软件许可证的许可。
字体：SIL Open Font License 1.1 保持字体开放的同时，允许它们在其他项目自由使用。
如果项目包含软件和其他部分的混合，可以通过说明明确各个许可证适用于项目的不同部分。常用的开源软件协议中，只有GPL许可证的开源软件是不能作为商业用途的，其他虽然有限制但是也是可以的。