开源许可证开发人员指南

已发表: 2022-03-11

并非所有开源许可证都是相同的。其中一些规定软件供应商有义务向软件的用户和开发人员授予专利许可。其他许可要求使用许可产品或库的开发人员在相同条款下提供该产品或库的源代码。其他人只是放弃代码，没有任何形式的保证或任何担忧。在本文中，我将尝试从软件用户和软件开发人员的角度强调最常用的开源许可证之间的主要区别。

揭开神秘的面纱——开源许可证

鸣叫

1984 年，Richard Stallman 开始创建自由操作系统的 GNU 项目时，他恢复了软件应该在开发人员、工程师和用户之间共享的想法。他们应该能够以与科学通常相同的方式以协作的方式改进它。

此选项与大多数软件公司和开发商选择用于分发和销售其程序的许可软件的通常概念形成对比。三十多年后的今天，开源软件缓慢地继续征服我们行业的广泛领域：Linux、Android、Apache 和 Git 是其类别中领先的开源产品的例子。

开源还是免费软件？

在本文中，在提及软件或许可证时，我将使用术语“开源”和“免费”作为同义词。在我看来，这两个术语都表达了相同的想法。 “开源”以实用和技术的方式表达它，使用“免费”将重点放在概念的哲学和政治含义上。

不幸的是，英语中的“免费”一词除了是与“自由”相关的形容词外，还意味着“免费”。这就是我通常更喜欢说“开源”的原因。

开源软件的共同属性

我想您已经大致了解什么是开源软件。但是当我们要讨论不同许可证的细节时，首先我们需要谈谈定义开源软件的特定属性。

首先：我不是律师，这不是法律建议。如有疑问，请参阅我所说的许可证的实际文本，并咨询您的法律顾问。

根据 Open Source Initiative 的说法，所有开源软件都是根据许可分发的，该许可赋予其用户和开发人员（被许可人）一些权利。完整列表可以在开源定义中查阅，但这里是一个基本摘要：

软件的免费再分发：软件可以作为产品出售或赠送或包含在软件包中。这可以在不支付任何版税的情况下完成。
许可软件的源代码要么包含在分发中，要么至少有广为人知的获取源代码的方法。此源代码可用于开发软件的修改版本。
允许创建派生作品，并且许可允许它们在与原始软件相同的条款和许可下分发。根据原始软件的许可证，在某些情况下，这些衍生作品必须通过更改名称或版本号来与原始软件区分开来，或者只能以源代码补丁的形式分发。
该软件可以由任何人或群体使用，并且可以在任何努力领域中使用，没有任何限制。

那么，我们可以在产品或项目的开发中使用开源软件吗？基本上，它取决于所用软件的许可证和最终产品的预期许可证。当您想将自己的代码作为开源发布并且您正在决定应该使用哪个许可证时，不同的许可证也很重要。

Copyleft

关于开源许可证的一个非常有趣的概念是通常称为 copyleft 的东西，它与版权相反。在使用版权保护知识产权（包括软件）不被复制或分发的情况下，copyleft 用于确保开源知识产权和软件可以作为开源进行复制或分发。

根据其实力，copyleft有两种：

强版权左：当作品衍生自其他强版权许可作品或链接到这些作品时，必须继续拥有强版权许可，甚至完全相同的许可。也就是说，那些开源的作品以后不能关闭。
弱 Copyleft：当作品使用弱 Copyleft 许可作品或与之链接的作品时，可以在其他许可下获得许可，甚至是闭源许可。在这种情况下，copyleft 只影响原始的弱 copyleft 许可作品。

也有没有 copyleft 的开源许可证：他们根本不关心派生软件的未来开放性。

放任

根据许可程度，许可证还可以分为：

严格的许可：当您不能将强大的许可软件与封闭源代码甚至更宽松的许可软件混合使用时。
许可许可：产品通常可以与闭源软件或具有完全开源许可的软件混合使用。

通常，强 copyleft 许可证也很严格，而弱 copyleft 许可证则更宽松，但不一定要那样。

开源许可证差异

存在许多开源许可证。开源计划已经批准了其中的 80 多个。有些是多余的，可以被认为与其他的等效。其他则特定于软件发布者的利益（例如 NASA 许可证），或特定环境或目的（例如教育社区许可证或开放字体许可证）。

许可证的这种扩散是基于许可证中的特定条款，这些条款添加到基本的开源属性中，允许或禁止其他用途。这些附加条件的示例包括：

Copyleft 的类型：弱或强或不存在。
许可类型：许可或严格。
在源代码或用户界面中添加版权声明的义务。
自动授予被许可人专利。
不仅将软件分发给的各方视为被许可人，而且将软件的用户视为被许可人（因此使用此类开源软件的云服务的人应该可以选择下载源代码软件）

混合代码与不同许可证的问题

根据我们之前已经说过的，一些许可是许可的，允许用户将代码与不同许可的源代码组合（可能带有附加条件）。这种情况将允许将这种开源许可软件与闭源软件混合使用。这种许可证的一个例子是 MIT 许可证。

其他的限制性更强，所以源代码只能与以类似方式获得许可的代码组合，并且最终结果必须使用相同的原始许可进行许可。此类许可证的一个示例是通用公共许可证 (GPL)。

也许您想将许可的代码与两个不同的限制性开源许可结合起来。使用开源自由来随心所欲地使用软件，您可以做到这一点。但是最终的程序不能重新分发，因为它应该在两个互不兼容的许可证下分发。

这种情况的一个例子是 ZFS。 ZFS 是一个非常先进和创新的文件系统，于 2005 年包含在 OpenSolaris 中。它是根据通用开发和分发许可 (CDDL) 条款获得许可的开源软件。虽然它是开源代码，但它不能集成到 Linux 内核中，因为 Linux 的源代码是根据通用公共许可证的条款分发的，这是另一个限制性的开源许可证。由于许可证冲突，无法分发使用 ZFS 支持编译的 Linux 内核的二进制文件。

只有当其中一个开源程序的所有所有者都同意更改许可或在软件许可中添加例外条款时，才能解决此类冲突。例如：很多 GPL 许可程序都与 OpenSSL 库链接。 OpenSSL 库分发已获得许可，要求在广告材料和任何重新分发中出现短语。这些额外的条件与 GPL 不兼容，因此使用 OpenSSL 的 GPL 产品的开发人员在他们的许可证中包含了一个例外，特别是允许与 OpenSSL 链接。

开源许可证的不同特征

现在我将尝试分析最流行的开源许可证，说明它们的不同特性，并提供一些关于何时使用它们的指南。根据 Black Duck 知识库，我已将它们从使用多到少排序。

GNU 通用公共许可证 (GPL)

GPL 是最流行的开源许可证。它是由 FSF 创建的，作为 GNU 项目的许可证，也是 Linux 内核的许可证。

其差异化特点：

强版权。
非常严格的执照。
它通常被称为“病毒”许可：如果您将您的代码链接到另一段根据 GPL 许可的代码并希望分发结果，则整个产品必须是 GPL 许可的。
它也是一个“包容性”许可：如果您正在开发软件并希望根据 GPL 许可它，您可以链接它或包含其他开源软件，只要该软件具有与 GPL 兼容的许可。它不需要 GPL 不要求的任何义务。

通常，使用的许可文本包括说明该软件是根据 GPL 版本 N（或任何更高版本）的条款分发的文本。

目前使用的 GPL 许可证有两个版本：v2 和 v3。第 3 版于 2007 年发布，用于解决自 1991 年第 2 版发布以来出现的一些问题。

GPL v3 包括一些额外的条款和条款，涉及与其他开源许可的兼容性规定，强制专利许可，定义使用 GPL 许可软件作为设备固件的条件，并考虑到数字版权管理的概念。

麻省理工学院许可证

开源许可证通常被称为 MIT 许可证，又名 X11 许可证，是一种非常宽松的非 Copyleft 许可证，只要您保留版权信息，并且知道该软件不提供任何形式的保证。

该许可证非常流行，并被多个项目使用，例如 X Window System、Ruby on Rails、jQuery 或 Node.js。

它与 GPL 兼容，因此您可以将 MIT 许可的代码混合到 GPL 软件中。

阿帕奇许可证 2.0

Apache 许可证由 Apache 软件基金会 (ASF) 创建，作为其 Apache HTTP 服务器的许可证。

就像 MIT 许可证一样，它是一个非常宽松的非 copyleft 许可证，允许将软件用于任何目的、分发、修改和分发其衍生作品，而无需担心版税。与 MIT 许可证相比，它的主要区别是：

使用 Apache 许可证，软件的作者将专利许可授予代码的任何用户或分发者。本专利许可适用于任何由软件作者许可的、会被他们创建的代码侵犯的专利。
Apache 许可证要求衍生作品中未修改的部分保留许可证。
在每个许可文件中，必须保留任何原始版权、专利、商标或归属声明。
在每次许可文件更改中，必须有通知说明文件已进行更改。
如果 Apache 许可软件包含 NOTICE 文件，则该文件及其内容必须保留在所有派生作品中。
如果有人故意向其作者发送 Apache 许可软件的贡献，则此贡献可以自动在 Apache 许可下使用。

这个许可很有趣，因为它有自动专利许可，以及关于贡献提交的条款。

它与 GPL 兼容，因此您可以将 Apache 许可代码混合到 GPL 软件中。

BSD 许可证

有 3 种不同的 BSD 许可证。所有这些都是非常宽松的许可证，没有 copyleft。

2 条款 BSD 许可证（或简化的 BSD 许可证）完全等同于之前解释的 MIT 许可证。

GNU 小通用公共许可证 (LGPL)

LGPL 由 FSF 创建，作为 GPL 的修改，具有较弱的左版，允许将 LGPL 许可的软件与任何其他软件链接。 LGPL 最初代表“图书馆通用公共许可证”，但后来改名为“小通用公共许可证”，代表 FSF 认为所有软件都应该是免费的，因此 LGPL 不应该是免费的。一般使用。

您可以将封闭源代码链接到 LGPL 库或软件并分发最终结果，只要：

您提供 LGPLed 部分的源代码，以及您对其所做的所有修改。
任何有足够知识的用户都可以用修改后的版本替换程序的 LGPL 部分。这可以通过将程序的 LGPL 部分作为动态库（Windows 中的 DLL，Linux/Unix 中的 .so）分发，或提供程序的非 LGPL 部分的目标代码来完成。

LGPL v3 与 GPLv3 兼容，因此您可以将 LGPLv3 代码输入 GPL 软件。

艺术许可证

艺术许可证，在其当前版本 2.0 中，是一个与 MIT 许可证类似的无版权许可的开源许可证。

MIT 许可证和艺术许可证之间的主要区别在于后者要求对代码所做的任何修改都必须明确说明。

该许可证几乎专门用于 Perl 社区。

当前的 Artistic License 2.0 与 GPL 兼容：您可以将 Artistic-Licensed 代码混合到 GPL 软件中。

微软公共许可证 (MS-PL)

Microsoft 公共许可证由该公司于 2008 年创建，作为其共享源计划创建的开源许可证之一。

这是一个严格的、弱的 Copyleft 许可证：它允许使用 MS-PL 代码创建和分发封闭源程序，但如果这些以源代码分发，它必须使用 MS-PL 作为派生作品的许可证。

MS-PL 与 GPL 不兼容。

Eclipse 公共许可证 (EPL)

Eclipse 公共许可证是 Eclipse 基金会为其集成开发环境创建的许可证。这是一个限制性和弱版权许可，在许多方面类似于 LGPL。它还包括自动授予专利许可的条款。

EPL 与 GPL 不兼容。

Mozilla 公共许可证 (MPL)

Mozilla 公共许可证 2.0 版是由 Mozilla 基金会为其产品创建的弱版权左许可许可证。

我们可以将此许可证视为类似于 LGPL，但主要区别在于 MPL 还允许将 MPL 代码段静态链接到闭源软件中。

MPL 在其当前版本 2.0 中与 GPL 兼容。这不适用于以前版本的 MPL。

通用开发和分发许可证 (CDDL)

CDDL 是由 Sun（现为 Oracle）基于 MPL 1.1 版创建的弱版权左许可许可。基本上，它具有与 MPL 相同的属性。其条款得到澄清，但没有实质性改变。

CDDL 是 Sun（现为 Oracle）为其许多产品（如 OpenSolaris 或 NetBeans 等）选择的开源许可证。

由于此许可证基于 MPLv1.1，因此此许可证与 GPL 不兼容，因此您不能将 CDDL 许可的源代码混入 GPL 许可的软件中。很多人说这是故意的，所以不能将 OpenSolaris 源代码引入 Linux 内核。

GNU Affero 通用公共许可证 (AGPL)

AGPL 是 GPL 的一个版本，具有更强大和更严格的 copyleft。它有义务将应用程序的源代码不仅提供给接收软件副本的人，而且还提供给通过计算机网络使用该软件的人。

该许可证由 FSF 创建，旨在为开发人员提供避免在网络服务器或云中执行开源软件时实际关闭的方法，因为 GPL 不能强制服务提供商向用户提供源代码. 在这种情况下，软件不会分发。

AGPLv3 与 GPL3 兼容。您可以将 AGPLv3 代码放入 GPLv3 代码中，只要最终结果在 AGPLv3 下获得许可即可。

ISC 执照

ISC 许可证是由 Internet 软件联盟 (ISC) 编写的许可自由软件许可证。在删除了一些被认为不必要的语言之后，它在功能上等同于 2 条款 BSD 和 MIT 许可证。

最初用于 ISC 自己的软件版本，它已成为 OpenBSD 的首选许可证（从 2003 年 6 月开始），以及其他项目。

它与 GPL 兼容：您可以将 ISC 许可代码混合到 GPL 软件中。

微软互惠许可证 (MS-RL)

Microsoft Reciprocal License 由该公司于 2008 年创建，作为其共享源计划创建的开源许可证之一。

它类似于前面解释的 MS-PL，但它有更强的 copyleft，类似于 LGPL、CDDL 和 EPL 的条件。它要求，如果您将代码与 MS-RL 许可的源代码混合并希望分发最终结果，则至少原始 MS-RL 许可的部分必须继续获得此许可的许可。

它与 GPL 不兼容。

公共领域 (CC0)

根据维基百科，“公有领域的作品是指知识产权已过期、被没收或不适用的作品”。将作品奉献给公共领域，作者放弃了他根据版权法对其拥有的所有权利。

Public Domain 下有几个软件项目，例如 SQLite，该库实现了一个可嵌入的简单 SQL 数据库引擎，它包含在其他几个项目中，例如 Mozilla 项目、Android 等。

有很多方法可以将软件专用于公共领域。知识共享创建了 CC0 公共领域奉献，这是一种将作品送入公共领域的通用方式。 FSF 建议使用此文本将软件专用于公共领域。

公共领域下的作品与任何开源或闭源许可证兼容，并且可以混合到任何其他软件中。

多重许可

有一些开源软件是双重甚至三重许可的。这意味着接收此多重许可软件的人可以选择他或她想要分发它的许可。由于每个许可证授予不同的权限并施加不同的义务，因此必须选择最能满足需求的许可证。

这是某些库的常见情况。例如，NSS 是 Mozilla 开发的一个库，它实现了 SSL/TLS 支持以及其他与安全相关的功能。它在 MPL、GPL 和 LGPL 许可下获得三重许可。

请选择许可证

很多人在没有任何书面许可的情况下在 GitHub 平台上发布代码。没有人应该使用该代码。我们不知道我们有什么使用它的权限。如果你使用它，你可能会因此被起诉。就好像这些人在取笑我们，说：“嘿，看看我做了什么！酷，不是吗？但你不能用，我只是想给你看！”。

请不要成为其中之一。如果您将代码上传到 GitHub 或类似的公共站点，请允许其他人使用并增强它。如果你不想想太多，以下是我的建议：

如果你想保持简单和宽容，允许每个人对你的代码做他们想做的事，只要他们向你提供归属并且不追究你的责任，请使用 MIT 许可证。
如果您想保持许可，允许每个人对您的代码做他们想做的事，但明智地列举版权法下的权利并授予这些权利，同时提供贡献者向用户明确授予专利权，请使用 Apache 2.0 许可证.
如果您关心共享修改并且不希望您的代码用于封闭式开发（既不封闭式软件产品也不封闭式硬件设备），请使用 GPL v3。
- 如果您不关心您的软件在封闭设备中使用的可能性，请使用 GPL v2。但是请加上“或任何更高版本”的句子，这样你的代码也可以在 GPLv3 项目中使用。
- 如果您不关心您的软件在封闭软件中使用的可能性，只要您的软件或使用它的部分在相同条款下继续开源，请使用 LGPL v3。
- 如果您希望通过网络使用您的软件的每个人都有权获取其源代码，请使用 AGPL v3。

毕竟，您可能已经厌倦了所有这些几乎是胡说八道的准法律胡言乱语。但是你知道吗？这是需要的。因为没有许可证，您就没有使用或分发任何代码的权利。