LGPL 與 Java
作者:David Turner自由軟體基金會 (FSF) 的立場始終認為,將應用程式動態連結到函式庫會產生一個衍生作品,該作品源自函式庫程式碼和應用程式碼。GPL 要求所有衍生作品都必須根據 GPL 的條款以整體授權,這種效應可以被描述為「遺傳性」。因此,如果應用程式連結到根據 GPL 授權的函式庫,則該應用程式也必須根據 GPL 授權。相比之下,根據 GNU 寬鬆通用公共授權條款 (LGPL) 授權的函式庫可以連結到專有應用程式。
2003 年 7 月,Slashdot 發布了一篇報導,聲稱我曾聲稱 LGPL 在 Java 的情況下無法按預期運作。這篇報導是基於對發送到 licensing@gnu.org 的問題的回應的誤解,並且在 Slashdot 報導中多次嘗試澄清該問題都未被理解。自那以後,我透過 licensing@gnu.org 和個人電子郵件收到了許多關於該報導的問題。
自由軟體基金會 (FSF) 的立場始終如一:LGPL 在所有已知的程式語言(包括 Java)中都能按預期運作。連結到 LGPL 函式庫的應用程式無需根據 LGPL 發布。應用程式只需遵循 LGPL 第 6 節中的要求:允許將新版本的函式庫連結到應用程式;並允許逆向工程來除錯。
Java 的典型安排是,應用程式使用的每個函式庫都作為單獨的 JAR (Java Archive) 檔案發布。應用程式使用 Java 的「import」功能來存取這些函式庫中的類別。當編譯應用程式時,會針對函式庫檢查函式簽名,從而建立連結。然後,應用程式通常是函式庫的衍生作品。因此,函式庫的著作權持有人必須授權發布該作品。LGPL 允許這種發布。
如果您發布導入 LGPL 函式庫的 Java 應用程式,則很容易遵守 LGPL。您的應用程式授權條款需要允許使用者修改函式庫,並對您的程式碼進行逆向工程以除錯這些修改。這並不意味著您需要提供原始碼或有關應用程式內部結構的任何詳細資訊。當然,使用者對函式庫所做的一些變更可能會破壞介面,導致函式庫無法與您的應用程式一起運作。您不必擔心這一點——修改函式庫的人有責任使其正常運作。
當您將函式庫與應用程式一起(或單獨)發布時,您需要包含函式庫的原始碼。但是,如果您的應用程式要求使用者自行取得函式庫,則您無需提供函式庫的原始碼。
從 LGPL 的角度來看,Java 和 C 之間的唯一區別在於 Java 是一種物件導向語言,支援繼承。LGPL 沒有針對繼承的特殊條款,因為不需要。繼承以與傳統連結相同的方式建立衍生作品,並且 LGPL 允許此類型的衍生作品,就像它允許普通函式呼叫一樣。