跳转到内容

FOSS 许可证/如何使源代码免费或开放

Add links
来自维基教科书，开放世界中的开放书籍

根据现行法律规范，软件受版权法保护。因此，FOSS 运动 开发了许多不同的 FOSS 许可证，使软件开发人员能够轻松声明他们授予其用户版权法专属于他们的某些权利。FOSS 许可证也作为 FOSS 开发者社区之间的协议。

FOSS 许可证有很多，它们的特征各不相同。在本入门手册的后面部分，我们将重点关注三大许可证：GNU GPL、LGPL 和 BSD 许可证。它们不仅代表了三种截然不同的 FOSS 许可风格，而且也是应用最广泛的许可证。[1] 表 1 帮助我们快速了解一般情况。[2]

表 1
被许可人/许可的义务 原始作品 衍生作品
原则上，重新发布是否应该提供源代码？ 在没有源代码的情况下重新发布时，源代码的单独分发者是否可以收取高于实际传输成本的费用？ 在附带源代码的情况下重新发布时，分发者是否可以收取高于实际传输成本的费用？ 可再许可？ 衍生作品应采用与原始作品相同的许可证 源代码是否需要公开？ 是否需要附上原始作品的版权声明？ 是否需要提供文档？
GNU GPL v 2 是 否 是 否 是，Copyleft 是 是 是
LGPL v 2.1 是 否 是 否 基于库的作品
是，Copyleft 是 是 是
将“使用库的作品”与库链接的可执行文件
否 否 是 是
BSD 许可证 否 是 是 否 否 否 是 否
艺术许可证 是 （始终重新分发源代码） 否 否 否 否 否 否
MIT 许可证 否 是 是 是 否 否 是 否
Apache 许可证 v 1.1 否 是 是 否 否 否 是 否
Apache 许可证 v 2.0 否 是 是 否 否 否 是 否
Mozilla 公共许可证 v 1.1 是 （始终重新分发源代码） 是 是 是，MPL 中描述的附加权利可以包含在附加文档中 是 是 是
Zlib/libpng 许可证 否 是 是 否 否 否 否 否
QPL 是 否 是 否 QPL 要求所有修改必须以与原始作品分离的形式存在，例如修补程序（不允许人们直接修改原始作品），并使用类似于其他许可证规范衍生作品的条款来规范修补程序。Qt 公开
否 是 是 否
通用公共许可证 v 1 是 否 是 是 否 是 是 否
学术自由许可证 v 2.1 否 是 是 是 否 是 是 否
PHP 许可证 v 3.0 否 是 是 否 否 否 是 否
开放软件许可证 v 2.1 否 是 是 是 是 是 是 是
Zope 公共许可证 v 2.0 否 是 是 否 否 否 是 是
Python 软件基金会许可证 v 2.1.1 否 是 是 否 否 否 是 是

表 1 中列出的 FOSS 许可证 具有以下共同特征

  • 原始作品的源代码是公开的。
  • 允许复制原始作品。
  • 允许分发原始作品。所有分发都应附带版权声明。
  • 许可授予是非排他性的、全球性的、免版税的，适用于所有目的。
  • 不提供保证。

但是，这些 FOSS 许可证 在如何行使这些权利方面彼此不同。例如，虽然始终要求作者提供访问源代码的途径，但重新发布者是否也需要提供此类访问途径，则因许可证而异。例如，在重新发布 BSD 许可的程序时，不需要提供源代码。

即使对于要求重新发布者提供源代码的许可证，对重新发布者可以收取的分发费也有不同的规定。GNU GPL 和 LGPL 对何时可以收取高于实际传输费的费用特别详细。这是因为 GNU GPL 和 LGPL 为重新发布者提供了多种方法来分发程序，无论是否附带源代码，同时确保重新发布仍然是自由软件。个人可以以任何她想要的价钱出售自由软件，因为市场会帮助将价格保持在合理范围内。但如果一个软件包在没有源代码的情况下出售，那么为源代码本身分发收取的费用不能超过实际传输成本。

关于衍生作品的条款差异很大。虽然访问原始作品的源代码是必需的，但访问衍生作品的源代码可能不是必需的。即使 FOSS 许可证要求衍生作品的源代码公开，它也可能不要求它们在与原始作品完全相同的许可证下许可。例如，虽然 GPL 许可的程序的衍生作品也必须在 GNU GPL 下获得许可，但 BSD 许可的程序的衍生作品不必在 BSD 许可证下获得许可。事实上，BSD 许可的程序的衍生作品甚至不必与源代码一起分发。

FOSS 许可证在是否允许将 FOSS 程序与专有程序组合方面也有所不同。当将不同的程序组合成一个更大的项目时，不可避免的是，这个更大的项目，虽然包含了所有或部分组合程序的源代码，但变成了所有组合程序的衍生作品。例如，项目 ABC 与 GPL 许可的程序 A、BSD 程序 B 和专有程序 C 相结合，并包含来自所有三个程序的源代码。作为程序 B 的衍生作品，项目 ABC 不需要在 BSD 许可证下获得许可，甚至不需要公开其源代码。但是，作为程序 A 的衍生作品，项目 ABC 需要在 GNU GPL 下获得许可。

因此，开发人员别无选择，只能在 GNU GPL 下许可整个项目 ABC，或者找到程序 A 的替代方案，特别是如果她希望将其作为专有软件项目。

这就是为什么专有公司认为 GNU GPL 具有所谓的“病毒”效应，并且被认为对专有软件开发模式不友好。但 GNU GPL 的设计是为了服务于自由软件社区的利益，而不是专有商业部门的利益。FSF 还设计了 LGPL，以鼓励在专有软件项目中更多地使用自由库。

以下是三种典型的 FOSS 许可证 - GNU GPL、LGPL 和 BSD - 的进一步解释。

GNU 通用公共许可证

[编辑 | 编辑源代码]

GNU GPL 是经典的 自由软件许可证。它也是所有 FOSS 许可证中最知名和使用最广泛的。GNU GPL 是为了实现 自由软件运动 定义的自由而开发的。它不仅仅是一个许可证，也是该运动背后基本理念的表达。

版权共享

[编辑 | 编辑源代码]
理念
GNU GPL 保证自由的方式也被称为“版权共享”。传统的专有模式说“版权所有，保留所有权利”，而 GNU GPL 则说“版权共享，所有权利反转”。版权共享不仅是关于在版权持有人发布时使原始作品免费，而且是关于在进一步分发和修改时保持其免费。虽然创建仅供内部使用衍生作品没有限制，但在将其分发给公众时，会应用版权共享以确保衍生作品与原始作品一样免费。
工作原理
版权共享防止 自由软件 变成 专有软件。它利用版权法来实现与其通常目的完全相反的目的。版权共享许可证不是私有化软件的手段，而是将授予作者的权利反转以保持软件免费。[3]

与 公共领域 中每个人都可以自由利用的作品不同，GPL 受许可的作品或版权共享作品受版权保护。GPL 受许可作品的作者不会放弃其作为版权持有人的权利，但会以不同于传统版权持有人的方式行使这些权利。

如果想要使软件免费的作者只是放弃他们作为版权持有人的权利并将他们的作品发布到公共领域，这将使作品面临被私有化和再次封闭的风险。相反，为了保持他们的作品及其衍生作品的自由，作者必须申明他们的权利，并以授予他们的独占权利，他们包括版权共享条款以规范其他人使用其作品的方式。通过在 GNU GPL 下许可他们的作品，作者允许用户拥有 自由软件运动 规定的权利。

同样，通过在 GNU GPL 下许可，作者要求希望分发该程序的人员以及希望修改该作品并分发修改后的作品的开发人员承担一些责任，以保持衍生作品与原始作品一样免费。

GNU GPL 的主要条款和条件

[编辑 | 编辑源代码]
用户的自由
当某个程序在 GNU GPL 下获得许可时，除了访问源代码的自由之外，用户还可以自由地
  1. 运行程序（第 0 节）。
  2. 复制程序（第 1 节）。
  3. 重新分发程序，即使用于商业目的，只要保留适当的版权声明和免责声明（第 1 节）。只要所有接收者都能获得 源代码，以目标代码或可执行形式重新分发也是可能的（第 3 节）。
  4. 准备和分发程序的衍生作品，只要衍生作品也在 GNU GPL 下获得所有第三方的许可（第 2 节）。
无担保
虽然作品的分发可以是商业性的，但作品本身是免费许可的。因此，GPL 受许可的软件没有担保（第 11、12 节）。分发者可以选择以收费的方式提供担保保护（第 1 节）。
直接来自作者的许可证
该作品不可再许可。当程序被重新分发时，接收者仍然从原始许可方那里获得许可。重新分发者不得对接收者在 GNU GPL 中授予的权利行使施加任何进一步的限制（第 6 节）。
接受和终止
通过修改或分发 GPL 受许可的程序，一个人表明他接受许可（第 5 节）。许可授予是不可撤销的，但当被许可人违反许可时，授予的权利将自动终止。但是，从她那里收到程序副本的人员的权利不受影响（因为他们从原始许可方那里获得了许可），只要他们完全遵守许可（第 4 节）。
与其他法律义务共存？
GNU GPL 不承认对接收者施加的任何矛盾条件。如果由于法院判决、专利侵权指控或任何其他原因导致无法遵守许可，那么接收者可能根本无法重新分发该程序（第 7 节）。GPL 受许可的程序不能合并到专有程序中，也不能与专有库链接。

完整的 GNU GPL 文本可以在 http://www.fsf.org/licenses/gpl.txt 找到。

FSF 还维护了一个关于 GNU GPL 的全面常见问题解答，可以访问 http://www.gnu.org/licenses/gpl-faq.html。

GNU 小通用公共许可证

[编辑 | 编辑源代码]

除了 GNU GPL 之外，FSF 还为库提供了一个特殊的版权共享许可证。GNU 小通用公共许可证 (LGPL) 允许 LGPL 受许可的库与专有软件链接。

此例外是用来服务不同的情况。鼓励在 GNU 系统上开发专有应用程序可能是一个战略决策。[4] 对于一个其功能可能被其他专有库所取代的自由库，在 LGPL 而不是 GNU GPL 下发布它可以鼓励更广泛的使用，[5] 因此可以使更多改进成为可能。随着更大的自由软件用户群，对自由软件的总体支持也会更广泛。[6]

但是，FSF 仍然鼓励人们对他们的库使用 GNU GPL 而不是 LGPL，特别是对于那些具有大量独特功能的库。这是因为那些有兴趣利用此类 GPL 受许可的库的人将不得不将他们的模块也发布为 GPL 受许可的软件，从而导致更多有用的模块和程序在自由软件环境中可用。[7]

LGPL 的主要条款和条件

[编辑 | 编辑源代码]

LGPL 在许多方面与 GNU GPL 相同，包括免责声明、声明许可证直接由作者颁发以及指定何时应用和终止许可的条款。此外，对用户适用的其他法律义务与 GNU GPL 相同。

在用户权利方面，LGPL 区分了使用库时两种不同的情况。 “基于库的作品” 指的是库本身或版权法下的任何衍生作品（第 0 节），而“使用库的作品” 指的是不包含库任何部分的衍生作品，但被设计为通过编译或链接与库一起工作的程序（第 5 节）。

基于库的作品
在“使用库的作品” 的情况下，即库本身及其衍生作品，其条款与 GNU GPL 中的条款非常相似。
  • 用户的自由
    1. 运行程序（第 0 节）。
    2. 复制程序（第 1 节）。
    3. 重新发布程序，即使是为了商业目的，只要保留适当的版权声明和免责声明（第 1 节）。 只要所有接收者都可以获得源代码，也可以重新发布对象代码或可执行文件形式（第 4 节）。
    4. 准备并分发程序的衍生作品，前提是衍生作品也根据 LGPL 授权给所有第三方（第 2c 节）。
    此外，可以选择将 GNU GPL 的条款应用于 LGPL 授权库的给定副本，特别是在将部分代码合并到不是库的程序中时（第 3 节）。
使用库的作品
在“使用库的作品” 的情况下，作品本身不受 LGPL 约束。 但当将“使用库的作品” 与库链接时，会创建库的衍生作品的可执行版本，此版本受 LGPL 约束（第 5 节）。

尽管 LGPL 允许作者分发可执行文件的对象代码（第 5 节）并在他们选择的条款下对其进行许可，但也要求这些条款允许客户修改作品以供自身使用并进行反向工程。 在分发可执行文件时，作者可以选择将库一起分发，前提是库的源代码以类似于分发 GPL 授权 程序的方式提供，或者不将库一起分发，而仅使用合适的共享库机制与库进行链接（第 6 节）。

通过创建此类别，LGPL 为 LGPL 授权库在专有程序中的使用提供了一种方式。 完整的 LGPL 文本可以在 http://www.fsf.org/licenses/lgpl.txt 找到。

BSD 风格许可

[edit | edit source]

伯克利软件发行版 (BSD) 许可 最初用于 伯克利软件发行版，这是一个在加州大学伯克利分校开发的 Unix 版本。[8] 通过更改版权声明和许可证中出现的拥有者、组织和年份的值，很容易遵循 BSD 许可模板来创建自己的许可证。 与 GNU GPL 和 LGPL 不同，BSD 风格许可不是复制许可。 BSD 许可允许人们自由分发和修改原始作品，但不要求修改后的作品与原始作品一样自由。 BSD 风格许可证相对简单，对软件的使用仅有限制。

  • 用户的自由
    1. 复制并重新发布程序，包括其源代码或二进制代码。 发行商没有义务提供源代码。
    2. 准备并分发衍生作品，包括其源代码或二进制代码。 作者可以自由地为衍生作品选择 FOSS 或专有许可证。
    3. 将程序合并到专有软件中。

原始 BSD 许可证（四条款 BSD）有一个广告条款。 修订后的 BSD 许可证（三条款 BSD）与 MIT 许可证 非常相似，但后者没有“对衍生作品不予认可” 的条款。 还有两条款 BSD，它去掉了认可条款，与 MIT 许可证最相似。[9]

多重许可

[edit | edit source]

需要注意的是，一项作品可以根据多个许可证进行授权。 许可证的选择反映了作者希望与受版权作品的用户之间建立的联系类型。 由于可能存在多种用户，以及多种可能的联系方式，版权持有者有权为不同情况选择不同类型的许可证。

以 OpenOffice 为例。 OpenOffice 根据 GNU GPL 和 Sun Industrial Standards Source License (SISSL) 进行双重授权。 虽然 OpenOffice 明确指出鼓励用户使用 GNU GPL 充分参与 OpenOffice 社区，但 SISSL 作为无法使用 GNU GPL 的开发人员和公司的替代方案提供。[10] ,[11] MySQL 是另一个例子。 MySQL 提供 GNU GPL 和商业许可证。 不想在 GNU GPL 下发布其应用程序的组织可以选择在 MySQL 商业许可证下使用 MySQL。[12]

文档怎么样？

[edit | edit source]

GNU 自由文档许可证 (GNU FDL)

[edit | edit source]

良好的文档和手册对于 FOSS 程序非常重要。 如果它们没有被授权为免费/开放，人们很难充分利用相关的 FOSS 程序。

虽然 GNU GPL 主要为软件设计的许可证，但它也可以用于非软件作品，只要在采用许可证时明确定义了“源代码”。[13] FSF 还提供专门为文档设计的许可证。 GNU 自由文档许可证 (GNU FDL 或 FDL) 是一种用于手册、教科书或其他文档的复制许可证，它赋予每个人复制和重新发布文档的自由，无论是否修改，无论是商业的还是非商业的。[14]

通过将 GNU FDL 应用于文档，作者授予用户制作作品的逐字副本、修改作品以及分发修改后的作品的权利。 由于它是一种 复制许可，因此它要求复制和分发 FDL 授权作品的修改也根据 FDL 授权。

知识共享许可证

[edit | edit source]
表 2
需要署名 允许商业用途 允许衍生作品 衍生作品应根据与原始作品相同的许可证授权
CC BY 是 是 是 否
CC BY-NC 是 否 是 否
CC BY-NC-ND 是 否 否
CC BY-NC-SA 是 否 是 是
CC BY-ND 是 是 否
CC BY-SA 是 是 是 是
CC NC • 否 否 是 否
CC NC-ND • 否 否 否
CC NC-SA • 否 否 是 是
CC ND • 否 是 否 否
CC SA • 否 是 是 是
GNU FDL 是 是 是 是

BY: 署名。 对于任何重新使用和分发，都需要注明原始作者的署名。

NC: 非商业性。 该作品不能用于商业目的。

ND: 禁止衍生作品。 该作品不能被修改或改编； 禁止基于该作品创建的衍生作品。

SA：署名-相同方式共享。只要结果作品是在与本许可证相同的许可证下授权的，就可以更改和转换作品，并准备作品的衍生作品。

• 从 2004 年开始，知识共享在第二个版本中将“署名”要求设为默认值。因此，在第二个版本中，只有上面列出的前六个 CC 许可证仍然存在。

受 FOSS 开发的启发，知识共享 提倡数字内容的开放，并敦促在越来越严格的默认规则面前，建立更合理、更灵活的版权层级。[15]

在 2002 年，知识共享公共许可证（CC 许可证）的第一个版本发布。通过识别作者的主要关切——即是否需要署名（署名，BY），是否允许用户进行商业用途（非商业，NC），是否允许用户制作衍生作品（无衍生作品，ND），以及何时允许制作衍生作品，是否要求它们以与原始作品完全相同的许可证授权（相同方式共享，SA）——知识共享 开发了 11 种不同的 CC 许可证。每种许可证都代表上述四个条件的独特组合。作者可以自由选择这 11 种许可证中的任何一种，并决定哪一种最适合他们的需求和作品。

在 2004 年，知识共享 发布了 CC 许可证的第二个版本。由于署名要求已得到 CC 许可证用户的广泛采用，署名要求已成为默认值，因此第二个版本中只有六种 CC 许可证。然而，第一个版本的 11 种许可证并没有被取代，仍然可以使用（表 2）。[16]

CC 许可证 专为除软件以外的所有类型的数字内容而设计，包括艺术作品、照片、音乐和文学文本。CC 许可证不涉及 FOSS 问题，因为所指作品中的思想是透明的，并且不会被编译成无法感知的形式。一些 CC 许可证不允许修改或盈利性使用，可能不被视为“免费”。但是，CC 许可证在将自由和开放的理念传播给更广大公众方面取得了成功，而这些公众可能不熟悉 FOSS 运动促成的最新软件发展。

脚注

[edit | edit source]
检索自 "https://wikibooks.cn/w/index.php?title=FOSS_Licensing/How_to_Make_the_Source_Free_or_Open&oldid=4227823"
华夏公益教科书