关于网景公共许可证

作者：Richard Stallman

---

网景公共许可证（Netscape Public License，简称 NPL），正如其在 1998 年最终设计的那样，是一个自由软件许可证——但它有三个主要的缺陷。一个缺陷传递了一个糟糕的哲学信息，另一个缺陷使自由软件社区处于弱势地位，而第三个缺陷在自由软件社区内造成了一个主要的实际问题。其中两个缺陷也适用于 Mozilla 公共许可证。由于这些缺陷，我们敦促您不要将 NPL 或 MPL 用于您的自由软件。

1. 并非所有用户都是平等的

我在 NPL 中注意到的第一个问题是，它没有像 GNU GPL 那样给予网景和我们其他人平等的权利。根据 NPL，我们只能按照 NPL 中规定的方式使用网景的代码，但网景可以以任何方式使用我们的更改——甚至在软件的专有许可版本中也可以。

这里的问题很微妙，因为它并没有使该程序变成非自由软件。它并没有阻止我们重新发布该程序，也没有阻止我们更改它；它没有剥夺我们的任何特定自由。从纯粹的实用角度来看，它可能看起来根本不是问题。

问题在于这一条件所体现的更深层的信息。它否定了我们社区赖以建立的平等合作理念，并表明从事自由程序的工作意味着为专有软件产品做出贡献。那些接受这一条件的人可能会因此而改变，而这种改变不会加强我们的社区。

针对这种不对称性提出的一种解决方案是为其设置时间限制——可能是三年或五年。这将是一个很大的改进，因为时间限制将否定有问题的更深层信息。

NPL 的另一个缺点最大限度地减少了这一条件的实际影响：它并非被设计为彻底的著作权保留。换句话说，它并没有非常努力地确保用户所做的修改可以作为自由软件提供。

MPL（Mozilla 公共许可证）没有这个问题。这是 MPL 和 NPL 之间的主要区别。

2. 非著作权保留

NPL 具有著作权保留的形式；它明确表示，用户所做的所有修改都必须根据 NPL 发布。但这仅适用于对现有代码的修改——不适用于添加的子程序（如果它们放在单独的文件中）。实际上，这意味着如果你想进行专有更改，很容易做到：只需将大部分代码放入单独的文件中，并将该集合称为“更大的作品”。只有添加到旧文件中的子程序调用才必须根据 NPL 发布，而这些调用本身用处不大。

缺乏真正的著作权保留并不是灾难性的；它不会使软件变成非自由软件。例如，X.org 的分发条款根本不尝试使用著作权保留，但 X.org 仍然是自由软件。BSD 也是非著作权保留的自由软件（尽管较旧的 BSD 条款有一个严重缺陷，不应效仿——如果您想发布非著作权保留的自由软件，请改用 X.org 条款）。受 NPL 约束的软件也是自由软件，尽管它不是著作权保留的，但这本身并不能使 NPL 比其他非著作权保留的自由软件许可证更糟糕。

然而，虽然这不是灾难性的，但这仍然是一个缺点。而且由于 NPL 看起来像是著作权保留，一些用户可能会对此感到困惑，并可能采用 NPL，认为他们正在为他们的软件获得著作权保留的好处，而事实并非如此。为了避免这种结果，我们需要努力教育人们了解一个不容易用几句话解释的问题。

3. 与 GPL 不兼容

NPL 中最严重的实际问题是它与 GNU GPL 不兼容。不可能将受 NPL 约束的代码和受 GNU GPL 约束的代码组合在一个程序中，即使是通过链接单独的目标文件或库也不行；无论如何这样做，都必须违反其中一个许可证。

之所以会发生这种冲突，是因为 GPL 非常重视著作权保留：它旨在确保对自由程序的所有更改和扩展都必须是自由的。因此，它不会留下通过将更改放入单独的文件中来使更改变成专有的漏洞。为了关闭这个漏洞，GPL 不允许将受著作权保留的程序与具有其他限制或条件（例如 NPL）的代码链接。

与 GPL 不兼容并不会使程序变成非自由软件；它不会引发根本的伦理问题。但这很可能会给自由软件社区带来严重问题，将代码库分成两个无法混合的集合。实际上，这个问题非常重要。

通过更改 GPL 来解决这个问题是可能的，但这将意味着放弃著作权保留——这弊大于利。但是可以通过稍微更改 NPL 来解决这个问题。（有关具体方法，请参见下文。）

4. 关于名称的说明

NPL 代表网景公共许可证（Netscape Public License），但 GPL 并不代表 GNU 公共许可证（GNU Public License）。我们许可证的全称是 GNU 通用公共许可证（GNU General Public License），缩写为 GNU GPL。有时人们会省略“GNU”一词，只写 GPL。

（这不是问题，只是您应该知道的事实。）

结论

由于问题 3 是最严重的，我希望人们能礼貌而理性地向网景解释解决它的重要性。解决方案是有的；他们只需要决定使用它们。

以下是一种可能的方法，允许将受 NPL 约束的代码和受 GPL 约束的代码链接在一起。可以通过向 NPL 添加以下两个段落来实现

A.1. You may distribute a Covered Work under the terms of the GNU
     General Public License, version 2 or newer, as published by the
     Free Software Foundation, when it is included in a Larger Work
     which is as a whole distributed under the terms of the same
     version of the GNU General Public License.

A.2. If you have received a copy of a Larger Work under the terms of a
     version or a choice of versions of the GNU General Public
     License, and you make modifications to some NPL-covered portions
     of this Larger Work, you have the option of altering these
     portions to say that their distribution terms are that version or
     that choice of versions of GNU General Public License.

这允许人们将受 NPL 约束的代码与受 GPL 约束的代码组合在一起，并根据 GNU GPL 的条款分发组合作品。

它允许人们根据 GNU GPL 的条款发布对此类组合作品的修改——但发布它们的最简单方法是根据 NPL。

当人们利用 A.2 时，他们的更改将仅根据 GNU GPL 的条款发布；因此这些更改将无法供网景在专有版本中使用。网景会认为这是不幸的，这是有道理的。

然而，NPL 为专有软件开发人员提供了一种简单的方法，使其更改完全无法供网景使用——通过将他们的代码放入单独的文件中，并将该组合称为“更大的作品”。实际上，这对他们来说比 A.2 对 GPL 用户更容易。

如果网景认为它可以接受（实际上）专有修改的麻烦，那么与 GPL 约束的修改的麻烦相比，肯定很小。如果网景认为实际考虑将鼓励大多数专有软件世界将其更改反馈给网景，而无需强迫，那么同样的理由也应该适用于自由软件世界。网景应该认识到这种改变是可以接受的，并采纳它，以避免让自由软件开发人员面临严重的困境。