关于 Netscape 公共许可证

Richard Stallman 著

---

Netscape 公共许可证（简称 NPL）作为1998年最终定稿的版本，虽然属于自由软件许可证，却存在三大缺陷：其一传递了不良的哲学理念，其二使自由软件社区处于弱势地位，其三在自由软件社区内部引发了重大实践问题。其中有两个缺陷同样存在于 Mozilla 公共许可证（MPL）。鉴于这些弊端，我们强烈建议您不要在自由软件项目中采用 NPL 或 MPL 许可证。

1. 并非平等对待所有用户

我在 NPL 中发现的第一个问题是，它未能像 GNU GPL 那样赋予 Netscape 公司和其他使用者平等的权利。根据 NPL 条款，我们只能按照许可证规定使用 Netscape 的代码，而 Netscape 却可以任意使用我们修改后的成果，甚至能将其用于专有软件许可版本中。

这个问题的微妙之处在于，它并未使程序变得非自由。它既没有阻止我们重新分发程序，也没有限制我们修改程序；更没有剥夺我们任何特定的自由。若单纯从实用主义角度来看，这或许根本算不上是个问题。

问题的深层症结在于这一条款传递的潜在信息。它否定了自由软件社区赖以生存的平等协作理念，暗示参与自由软件开发就意味着为专有软件产品做贡献。接受这一条款的人很可能会受其影响，而这样的影响不会增强我们的社区。

针对这种权利不对等，有人提议设置时限——比如三年或五年。这将是一大改进，因为时限能消除那个隐含的深层问题。

这一条款的实际影响因 NPL 的另一缺陷而有所减弱：该许可证并非彻底的 copyleft 设计。换言之，它并未真正着力确保用户修改后的版本必须保持自由软件属性。

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

2. 并非 copyleft 许可证

NPL 采用了 copyleft 的形式，其明确规定用户的所有修改都必须基于 NPL 协议发布。但这一要求仅适用于对现有代码的修改——若新增子程序被置于独立文件中，则不受此限。从实际操作来看，这意味着若想制作专有修改版本十分简便：只需将主要代码放入独立文件，并将整个作品称为"更大作品"。唯有添加到旧文件中的子程序调用需遵循 NPL 协议发布，而这些代码片段本身并无太大实用价值。

缺乏真正的 copyleft 条款并非灾难性缺陷，这并不会使软件变成非自由软件。例如，X.org 的发布条款完全未采用 copyleft 机制，但 X.org 依然是自由软件。BSD 协议同样属于非 copyleft 的自由软件（尽管旧版 BSD 条款存在 严重缺陷，不应被效仿——若您想发布非 copyleft 的自由软件，建议改用 X.org 的条款）。遵循 NPL 的软件同样属于 自由软件，尽管没有 copyleft 保护，仅就这一点而言，NPL 并不比其他非 copyleft 自由软件许可证更糟糕。

然而，尽管这并非灾难性的问题，但终究是一个缺陷。更棘手的是，由于 NPL 表面上形似 copyleft 许可证，部分用户可能会产生误解，他们或许会误以为采用 NPL 就能为自己的软件获得 copyleft 的保护效果，而事实却并非如此。为避免这种误解，我们必须付出大量努力来向公众阐明这个难以三言两语解释清楚的问题。

3. 不兼容 GPL 许可证

NPL 最严重的实际问题在于它与 GNU GPL 不兼容。无论是通过连接独立的目标文件还是库文件，都无法将遵循 NPL 的代码与遵循 GNU GPL 的代码合并到同一个程序中。无论如何操作，都必然违反其中一项许可协议。

这一冲突的根源在于 GPL 对 copyleft 的严格要求：该许可证的设计初衷就是确保自由程序的所有修改和扩展都必须保持自由。因此它没有留下"通过将修改内容放入独立文件就能转为专有"的漏洞。为了堵住这个漏洞，GPL 不允许将采用 copyleft 的程序与其他附加限制条件的代码（比如 NPL 许可的代码）进行连接。

与 GPL 不兼容并不会使程序变成非自由软件，这并不涉及根本性的道德问题。但它很可能会给自由软件社区带来严重问题——将代码库割裂成两个无法混合的集合。从实际角度来看，这个问题至关重要。

通过修改 GPL 来解决这个问题是可行的，但这将意味着放弃 copyleft——弊大于利。不过只需对 NPL 稍作修改就能解决这个问题。（具体方法请见下文说明。）

4. 关于名称的说明

NPL 指 Netscape 公共许可证，但是 GPL 不是 GNU 公共许可证。该许可证的全称是 GNU 通用公共许可证，简称 GNU GPL。人们有时不再写 “GNU” 一词而是直接写 GPL。

（这不是问题，只是帮你了解一下事实。）

结论

鉴于第三个问题最为严重，我希望大家能够以礼貌且理性的态度向 Netscape 公司阐明解决该问题的重要性。可行的解决方案已然存在，现在只需他们做出采用的决定。

以下是一种允许将遵循 NPL 的代码与遵循 GPL 的代码进行连接的可行方案。只需在 NPL 中添加以下两个条款即可实现：

A.1. 当涵盖作品作为整体以相同版本的 GNU 通用公共许可证条款发布时，您可以选择
     按照自由软件基金会发布的 GNU 通用公共许可证第2版或更新版本的条款来分发
     该涵盖作品（作为更大作品的一部分）。

A.2. 若您根据某一版本或可选版本的 GNU 通用公共许可证条款获得了更大作品的副本，
     并对该更大作品中受 NPL 保护的部分进行了修改，您可选择将这些部分的发布条
     款更改为该版本或可选版本的 GNU 通用公共许可证。

这样便允许将遵循 NPL 的代码与遵循 GPL 的代码相结合，并依据 GNU GPL 的条款发布组合后的作品。

该方案允许人们依据 GNU GPL 条款发布对此类组合作品的修改版本——不过最简单的发布方式仍是采用 NPL 许可。

当人们运用 A.2条款时，其修改内容将仅依据 GNU GPL 条款发布；这意味着 Netscape 公司无法将这些修改用于专有版本。Netscape 公司将此视为憾事，实属情理之中。

然而，NPL 为专有软件开发者提供了更便捷的途径，只需将代码置于独立文件并将组合体称为"更大作品"，就能完全避免 Netscape 使用其修改版本。实际上，对此类开发者而言，这比 GPL 用户运用 A.2条款更为简便。

如果 Netscape 公司能够容忍（实质上）专有修改版本带来的困扰，那么相比之下，GPL 授权修改版本造成的影响理应更小。若 Netscape 公司相信实际考量会促使专有软件界在不受强制的情况下，主动将修改版本回馈给 Netscape 公司，那么同样的理由也适用于自由软件领域。Netscape 公司应当认识到这一修改方案是可接受的，并予以采纳，以免让自由软件开发者陷入严峻的两难困境。