关于网景公共许可证（原始版本）

作者：Richard Stallman

---

网景公共许可证或 NPL 代表着设计新的自由软件分发条款的一次认真尝试。这是一个有趣的尝试，但它存在需要纠正的重大缺陷。其中一个缺陷非常严重，我们应将其视为使程序成为非自由软件。其他的缺陷则具有不同的后果：一个发送了错误的哲学信息，而另一个则为自由软件社区制造了一个重大的实际问题。

NPL 仍然是一个草案，并且仍在更改中；本文的目的不是攻击和谴责，而是鼓励 NPL 的改进。如果在您阅读本文时，其中一些问题已经得到纠正，那就更好了，我们可以把那些过时的问题放在一边。

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

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

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

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

针对这种不对称性的一种拟议的解决方案是对此设置时间限制——也许是三到五年。这将是一个很大的改进，因为时间限制将否认有问题的更深层信息。

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

2. 不是著作权

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

缺乏真正的著作权并不是灾难性的；它不会使软件成为非自由软件。例如，XFree86 分发条款根本不尝试使用著作权，但 XFree86 仍然是自由软件。BSD 也是非著作权的自由软件（尽管 BSD 条款有一个严重缺点，不应该效仿——如果您想发布非著作权的自由软件，请改用 XFree86 条款）。网景软件也可以是自由软件，而无需著作权。

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

3. 不尊重隐私

NPL 中的下一个问题是无法容忍的：如果您进行更改，则必须发布它。不允许为自己使用进行私人更改；也禁止仅向少数朋友分发更改。

当我们考虑自由软件的问题时，我们通常会关注分发和修改的自由，因为这是软件开发人员最常试图阻止的事情。但是，当您不想分发副本时，不分发的自由也很重要。例如，进行修改而不将其展示给任何人的自由是我们所称的“隐私”的一部分。将您的修改分发给少数朋友，但不将其展示给公众（或尚未展示）的自由也是至关重要的。（当然，如果程序是自由的，您的朋友将可以自由地将其传递给其他人，如果他们愿意的话——但他们没有义务这样做。）

纠正 NPL 以尊重这种基本自由绝对是至关重要的，我们的社区必须坚定地坚持这一点。不值得为了一个额外的程序而牺牲至关重要的自由，无论它多么有用和令人兴奋。

4. 与 GPL 不兼容

NPL 中还有另一个严重问题：它与 GNU GPL 不兼容。不可能将 NPL 覆盖的代码和 GNU GPL 覆盖的代码组合到一个程序中，即使通过链接单独的目标文件或库也不行；无论如何完成，它都必须违反其中一个许可证。

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

与 GPL 不兼容并不会使程序成为非自由软件；它不会引发基本道德问题。但是，它很可能会为我们的社区制造一个严重的问题，将代码库划分为两个无法混合的集合。实际上，需要解决这个问题。

通过更改 GPL 来解决这个问题是可能的，但这将意味着放弃著作权——这造成的危害将大于好处。但是，可以通过对 NPL 进行小幅更改来解决这个问题。（有关具体方法，请参见下文。）

5. 关于名称的说明

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

结论

由于问题 3 和 4 最为严重，我希望人们可以礼貌而理性地向网景解释解决这些问题的重要性。解决方案是可行的；他们只需要决定使用它们即可。有传言说网景已经决定纠正问题 3——但是让他们知道这对您很重要不会有任何坏处。没有消息说他们计划纠正问题 4。

以下是一种可能的方式，允许将 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 覆盖的修改带来的麻烦就微不足道了。如果网景认为实际考虑因素会鼓励大多数专有软件世界将其更改发布回网景，而无需强制执行，那么同样的理由也应该适用于自由软件世界。网景应认识到此更改是可以接受的，并采纳它，以避免让自由软件开发人员陷入严重的困境。