關於 Netscape 公共許可證

作者：Richard Stallman

---

Netscape 公共許可證（NPL）在 1998 年最終設計完成，它是一個自由軟體許可證，但它有三個主要缺陷。其中一個缺陷傳達了錯誤的哲學訊息，另一個使自由軟體社群處於弱勢地位，而第三個則在自由軟體社群內部造成了重大的實際問題。其中兩個缺陷也適用於 Mozilla 公共許可證。由於這些缺陷，我們強烈建議您不要將 NPL 或 MPL 用於您的自由軟體。

1. 並非所有使用者都是平等的

我在 NPL 中注意到的第一個問題是，它不像 GNU GPL 那樣給予 Netscape 和我們其他人平等的權利。根據 NPL，我們只能按照 NPL 中的規定使用 Netscape 的程式碼，但 Netscape 可以以任何方式使用我們的變更——即使是在軟體的專有授權版本中。

這裡的問題很微妙，因為這不會使程式變成非自由軟體。它不會阻止我們重新發布程式或更改程式；它沒有剝奪我們的任何特定自由。從純粹務實的角度來看，這可能根本不像是一個問題。

問題在於此條件所包含的更深層次的訊息。它否定了我們社群賴以生存的平等合作理念，並表示從事自由程式的工作意味著為專有軟體產品做出貢獻。那些接受此條件的人很可能會因此而改變，而這種改變不會增強我們的社群。

針對這種不對稱性，一個建議的解決方案是對其設定時間限制——也許是三到五年。這將是一個很大的改進，因為時間限制會否定有問題的更深層次訊息。

NPL 的另一個缺點最大限度地減少了此條件的實際影響：它並非被設計為徹底的著作權保護（copyleft）。換句話說，它並沒有非常努力地確保使用者所做的修改可以作為自由軟體使用。

MPL（Mozilla 公共許可證）沒有這個問題。這是 MPL 和 NPL 之間的主要區別。

2. 不是著作權保護（Copyleft）

NPL 具有著作權保護（copyleft）的形式；它明確指出，使用者所做的所有修改都必須根據 NPL 發布。但這僅適用於對現有程式碼的修改——不適用於新增的子程式，如果它們被放在單獨的文件中。實際上，這意味著如果您想進行專有變更，這很容易：只需將您的大部分程式碼放入單獨的文件中，並將該集合稱為「較大的作品」。只有添加到舊文件中的子程式調用才必須根據 NPL 發布，而且它們本身不會非常有用。

缺乏真正的著作權保護（copyleft）並非災難；它不會使軟體變成非自由軟體。例如，X.org 發行條款根本不嘗試使用著作權保護（copyleft），但 X.org 仍然是自由軟體。BSD 也是非著作權保護（non-copylefted）的自由軟體（儘管較舊的 BSD 條款有嚴重的缺陷，不應模仿——如果您想發布非著作權保護（non-copylefted）的自由軟體，請改用 X.org 條款）。受 NPL 保護的軟體也是自由軟體，但沒有著作權保護（copyleft），而且就其本身而言，這並不會使 NPL 比其他非著作權保護（non-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。

（這不是問題，只是一個您應該知道的事實。）

結論

由於問題 3 最為嚴重，我希望人們能夠禮貌且理性地向 Netscape 解釋解決這個問題的重要性。解決方案是可行的；他們只需要決定使用它們。

這裡有一個可能的方法來允許將受 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 的條款發布；因此，這些變更將無法供 Netscape 在專有版本中使用。Netscape 會認為這是不幸的，這是可以理解的。

然而，NPL 為專有軟體開發人員提供了一種簡單的方法，使其變更完全無法提供給 Netscape——通過將他們的程式碼放入單獨的文件中，並將組合稱為「較大的作品」。事實上，對他們來說，這比 A.2 對 GPL 使用者來說更容易。

如果 Netscape 認為它可以忍受（實際上）專有修改的麻煩，那麼相比之下，GPL 保護的修改的麻煩肯定很小。如果 Netscape 認為實際的考量會鼓勵大多數專有軟體界將其變更發布回 Netscape，而無需強迫，那麼同樣的理由也應該適用於自由軟體界。Netscape 應該認識到這種改變是可以接受的，並採納它，以避免使自由軟體開發人員面臨嚴重的困境。