关于 Netscape 公共许可证(初始版本)

Richard Stallman 著

---

Netscape 公共许可证(NPL)代表着设计新型自由软件分发条款的重要尝试。这是一次有趣的尝试,但存在需要修正的重大缺陷。其中一项缺陷尤为严重,我们应认定其导致软件不符合自由标准。其他缺陷则带来不同影响:一则传递了不良的哲学信号,另一则给自由软件社区造成了重大实际问题。

NPL 目前仍处于草案阶段,且仍在不断修改中;本文的目的并非抨击与谴责,而是希望推动 NPL 的改进。若您读到本文时部分问题已得到修正,那再好不过,我们便可将这些过时议题搁置一旁。

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

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

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

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

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

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

2. 并非 copyleft 许可证

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

缺乏真正的 copyleft 条款并非灾难性缺陷;这并不会使软件变成非自由软件。例如,XFree86 的发布条款完全未采用 copyleft 机制,但 XFree86 依然是自由软件。BSD 协议同样属于非 copyleft 的自由软件(尽管旧版 BSD 条款存在 严重缺陷,不应被效仿——若您想发布非 copyleft 的自由软件,建议改用 XFree86 的条款)。尽管不是 copyleft,Netscape 公司的软件也可以属于 自由软件。

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

3. 没有尊重隐私

NPL 中还存在一个致命问题:任何修改都必须公开发布。既不允许为自用而私下修改,也禁止仅向少数朋友分发修改版本。

当我们讨论自由软件的核心问题时,通常关注的是分发和修改的自由,因为软件开发者最常试图限制的正是这些权利。但同样重要的是"不"分发的自由——当你不愿意时保留副本的权利。例如,进行修改却不必向任何人展示的自由,正是我们称之为“隐私”的重要组成部分。而仅将修改版本分享给少数朋友却不公开(或暂不公开)的自由同样至关重要。(当然,如果程序是自由的,你的朋友可以选择将其传播给他人——但他们没有义务必须这样做。)

必须修正 NPL 以保障这一基本自由,这一点至关重要,我们的社区必须坚决坚持。无论某个程序多么实用、多么令人振奋,都不值得为此牺牲至关重要的自由。

4. 不兼容 GPL 许可证

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

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

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

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

5. 关于名称的说明

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

结论

鉴于第三和第四个问题最为严重,我希望大家能够以礼貌且理性的态度向 Netscape 公司阐明解决该问题的重要性。可行的解决方案已然存在,现在只需他们做出采用的决定。有消息说 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 公司应当认识到这一修改方案是可接受的,并予以采纳,以免让自由软件开发者陷入严峻的两难困境。