GNU GPL 許可證常見問題解答（六）

本文由高級諮詢師薛亮據自由軟體基金會（FSF）的英文原文翻譯而成，這篇常見問題解答澄清了在使用 GNU 許可證中遇到許多問題，對於企業和軟體開發者在實際應用許可證和解決許可證問題時具有很強的實踐指導意義。

1. 關於 GNU 項目、自由軟體基金會（FSF）及其許可證的基本問題
2. 對於 GNU 許可證的一般了解
3. 在您的程序中使用 GNU 許可證
4. 依據GNU許可證分發程序
5. 在編寫其他程序時採用依據 GNU 許可證發布的程序
6. 將作品與依據 GNU 許可證發布的代碼相結合
7. 關於違反 GNU 許可證的問題

6 將作品與依據 GNU 許可證發布的代碼相結合

6.1 GPL v3 是否與 GPL v2 兼容？

不兼容。許多要求已經從 GPL v2 變為 GPL v3，這意味 GPL v2 中的精確要求並不體現在 GPL v3 中，反之亦然。例如，GPL v3 的終止條件比 GPL v2 的終止條件更為寬泛，因此與 GPL v2 的終止條件不同。

由於這些差異，兩個許可證不兼容：如果您試圖將依據 GPL v2 發布的代碼與依據 GPL v3 發布的代碼組合，則將違反 GPL v2 的第 6 部分。

但是，如果代碼依據 GPL 「v2 或更高版本」發布，則與 GPL v3 兼容，因為 GPL v3 是其允許的選項之一。

6.2 GPL v2 是否有提供安裝信息的要求？

GPL v3 明確要求再分發中包含完整的必要的「安裝信息」。GPL v2 不使用該術語，但它需要再分發中包含用於控制可編譯和安裝可執行文件的腳本以及完整和相應的源代碼。這涵蓋了 GPL v3 中稱為「安裝信息」的部分內容，但不包括所有內容。因此，GPL v3 對安裝信息的要求較強。

6.3 各種 GNU 許可證之間如何相互兼容？

各種 GNU 許可證彼此之間具有廣泛的兼容性。下面是唯一的一種您不能將遵循兩種 GNU 許可證的代碼結合起來的情況：將遵循舊版本許可證的代碼與遵循該許可證新版本的代碼進行結合。

以下是 GNU 許可證的各種結合的詳細兼容性矩陣，以便為特定情況提供易於使用的參考。它假設有人依據其中一個許可證編寫了一些軟體，而您希望以某種方式將該軟體的代碼結合到您要發布的項目（您自己的原始作品或其他人的軟體的修改版本）中。在表頂部的列中找到項目的許可證，並在左側的一行中找到其他代碼的許可證。它們交叉的單元格會告訴您這種結合是否被允許。

當我們說「複製代碼」時，我們的意思就是：您正在從一個源代碼中獲取一段代碼（無論是否修改），並將其插入到自己的程序中，從而基於第一部分代碼形成一個作品。當您編譯或運行代碼時，「使用庫」意味著您不直接複製任何源代碼，而是通過鏈接、導入或其他典型機制將源代碼綁定在一起。

矩陣中每個標明 GPL v3 的地方，其關於兼容性的聲明也同樣適用於 AGPL v3。

兼容性矩陣

角註：

1. 在這種情況下，當結合代碼時，您必須遵守 GPL v2 的條款。您不能適用更高版本的條款。
2. 在這種情況下，您可以依據 GPL v2 或更高版本發布您的項目（您的原始作品和/或您收到並修改的作品），請注意，您使用的其他代碼仍然只能遵循 GPL v2。只要您的項目依賴於該代碼，您將無法將項目的許可證升級到 GPL v3 或更高版本，整個作品（您的項目和其他代碼的任意結合）只能依據 GPL v2 的條款傳遞。
3. 如果您有能力依據 GPL v2 或任何更高版本發布項目，您可以選擇依據 GPL v3 或更高版本發布該項目，一旦您執行此操作，您就可以結合依據 GPL v3 發布的代碼。
4. 如果您有能力依據 LGPL v2.1 或任何更高版本發布項目，您可以選擇依據 LGPL v3 或更高版本發布該項目，一旦您這樣做，您就可以結合依據 LGPL v3 發布的代碼。
5. 在這種情況下結合代碼時，您必須遵守 LGPL v2.1 的條款。您不能適用更高版本 LGPL 中的條款。
6. 如果這樣做，只要項目包含僅依據 LGPL v2.1 發布的代碼，您將無法將項目的許可證升級到 LGPL v3 或更高版本。
7. LGPL v2.1 允許您將遵循自 GPL v2 之後任何版本 GPL 的代碼進行重新許可。如果在這種情況下可以將遵循 LGPL 的代碼切換為使用適當版本的 GPL（如表所示），則可以進行此種結合。
8. LGPL v3 是 GPL v3 加上在這種情況下可以忽略的額外許可權。
9. 由於 GPL v2 不允許與 LGPL v3 結合，因此在這種情況下，您必須依據 GPL v3 的條款傳遞項目，因為它允許此種結合。

6.4 「聚合」 （ aggregate ） 與其他類型的「修改版本」有什麼區別？（同 2.25）

「聚合」由多個單獨的程序組成，分布在同一個 CD-ROM 或其他媒介中。GPL 允許您創建和分發聚合，即使其他軟體的許可證不是自由許可證或與 GPL 不兼容。唯一的條件是，發布「聚合」所使用的許可證不能禁止用戶去行使「聚合」中每個程序對應的許可證所賦予用戶的權利。

兩個單獨的程序還是一個程序有兩個部分，區分的界限在哪裡？這是一個法律問題，最終由法官決定。我們認為，適當的判斷標準取決於通信機制（exec、管道、rpc、共享地址空間內的函數調用等）和通信的語義（哪些信息被互換）。

如果模塊們被包含在相同的可執行文件中，則它們肯定是被組合在一個程序中。如果模塊們被設計為在共享地址空間中鏈接在一起運行，那麼幾乎肯定意味著它們組合成為一個程序。

相比之下，管道、套接字和命令行參數是通常在兩個獨立程序之間使用的通信機制。所以當它們用於通信時，模塊們通常是單獨的程序。但是，如果通信的語義足夠親密，交換複雜的內部數據結構，那麼也可以視為這兩個部分合併成了一個更大的程序。

6.5 我在使用 GPL 程序的源代碼時是否具有 「合理使用」 （ fair use ） 許可權？（同 4.17）

是的，您有。「合理使用」是在沒有任何特別許可的情況下允許的使用。由於您不需要開發人員的許可來進行這種使用，無論開發人員在許可證或其他地方對此怎麼說，您都可以執行此操作，無論該許可證是 GNU GPL 還是其他自由軟體許可證。

但是，請注意，沒有全世界範圍普適的合理使用原則；什麼樣的用途被認為「合理」因國而異。

6.6 美國政府可否對遵循 GPL 的程序進行改進並發布？（同 3.14）

可以。如果這些改進是由美國政府僱員在僱傭期間編寫的，那麼這些改進屬於公有領域。不過，GNU GPL 仍然涵蓋了整體的改進版本。在這種情況下沒有問題。

如果美國政府使用承包商來完成這項工作，那麼改進本身可以被 GPL 覆蓋。

6.7 GPL 對於與其所覆蓋的作品進行靜態或動態鏈接的模塊有不同的要求嗎？

沒有。將 GPL 覆蓋的作品靜態或動態地鏈接到其他模塊是基於 GPL 覆蓋的作品構建結合作品。因此，GNU GPL 的條款和條件將覆蓋整個結合作品。另請參閱：6.24 如果我在 GPL 軟體中使用了與 GPL 不兼容的庫，會出現什麼法律問題？

6.8 LGPL 對於與其所覆蓋的作品進行靜態或動態鏈接的模塊有不同的要求嗎？

為了遵守 LGPL（任何現有版本：v2、v2.1 或 v3）：

（1）如果您靜態鏈接到 LGPL 庫，您還必須以對象（不一定是源代碼）格式提供應用程序，以便用戶有機會修改庫並重新鏈接應用程序。

（2）如果您動態鏈接已經存在於用戶計算機上的 LGPL 庫，則不需要傳遞庫的源代碼。另一方面，如果您自己將可執行的 LGPL 庫與您的應用程序一起傳遞，無論是靜態還是動態鏈接，還必須以 LGPL 所提供的方式之一來傳遞庫的源代碼。

6.9 如果庫依據 GPL（而不是 LGPL）發布，這是否意味著使用它的任何軟體必須遵循 GPL 或與 GPL 兼容的許可證？

是的，因為程序實際上與庫進行了鏈接。因此，GPL 的條款適用於整個結合作品。與庫鏈接的軟體模塊可能遵循與GPL兼容的不同許可證，但整體作品必須遵循 GPL。另見：「2.23 許可證與 GPL 兼容是什麼意思？」

6.10 您有一個遵循 GPL 的程序，我想將它與我的代碼進行鏈接，來構建一個專有程序。那麼事實上，我鏈接到您的程序意味著我必須讓我的程序遵循 GPL 許可證？

不完全是。這意味著您必須依據與 GPL 兼容的許可證（更準確地說，與您鏈接的結合作品中所有其他代碼所適用的一個或多個 GPL 版本相兼容）發布您的程序。然後，結合作品本身就可以遵循這些 GPL 版本。

6.11 如果是這樣的話，有沒有機會依據 LGPL 獲得您的程序許可？

您可以這麼要求，但絕大多數的作者都會堅定不移地說不。GPL 的想法是，如果要將我們的代碼包含在程序中，您的程序也必須是自由軟體。GPL 的意圖是給您施加壓力，讓您以能夠使其成為我們社區一部分的方式來發布您的程序。

您始終擁有不使用我們代碼的合法選擇。

6.12 我們構建專有軟體的項目不能使用遵循 GPL 的某個 GNU 程序。您會為我們提供例外嗎？ 這將意味著該程序擁有更多用戶。

對不起，我們沒有這樣的例外。這樣做是不對的。

最大化用戶數量不是我們的目標。相反，我們正在努力為儘可能多的用戶提供至關重要的自由。一般來說，專有軟體項目是阻礙而不是實現軟體自由的原因。

我們偶爾提供許可證例外來協助一個依據 GPL 以外的許可證生產自由軟體的項目。不過，我們必須看到一個很好的理由，即這個項目為什麼會推動自由軟體的發展。

我們有時也會改變軟體包的分發條款，這顯然是為自由軟體事業服務的正確方法；但是我們對此非常謹慎，所以您必須向我們展示非常有說服力的理由。

6.13 如果一個編程語言解釋器是依據 GPL 發布的，這是否意味著由它解釋的程序必須遵循與 GPL 兼容的許可證？

當解釋器只是解釋一種語言時，答案是否定的。被解釋程序對於解釋器來說只是數據；根據版權法，像GPL這樣的自由軟體許可證不能限制您使用解釋器的數據。您可以使用任何數據（被解釋程序），以任何您喜歡的方式運行它，並且沒有任何要求規定您必須將數據授權給任何人。

然而，當解釋器被擴展以向 其他程序 （ facilities ） （通常但不一定是庫）提供 「綁定」 （ bindings ） 時，被解釋程序通過這些綁定有效地與其使用的程序相關聯。因此，如果這些程序是依據 GPL 發布的，則使用它們的被解釋程序必須以與 GPL 兼容的方式發布。JNI（Java Native Interface）是這種綁定機制的一個例子；以這種方式訪問​​的庫與調用它們的 Java 程序動態鏈接。這些庫也與解釋器聯繫在一起。如果解釋器與這些庫靜態鏈接，或者如果它被設計為與這些特定庫動態鏈接，那麼也需要以與 GPL 兼容的方式發布。

另一個類似且非常常見的情況是為庫提供解釋器，它們能夠自我解釋。例如，Perl 帶有許多 Perl 模塊，Java 實現帶有許多 Java 類。這些庫和調用它們的程序總是動態鏈接在一起。

結果是，如果您選擇在程序中使用遵循 GPL 的 Perl 模塊或 Java 類，則必須以與 GPL 兼容的方式發布該程序，無論結合後的 Perl 或 Java 程序所依之運行的 Perl 或 Java 解釋器中使用什麼樣的許可證。

6.14 如果編程語言解釋器遵循與 GPL 不兼容的許可證，我可以在其上運行遵循 GPL 的程序嗎？

當解釋器解釋一種語言時，答案是肯定的。被解釋程序對於解釋器來說只是數據；GPL 不會限制您處理程序時所使用的工具。

然而，當解釋器被擴展以向 其他程序 （ facilities ） （通常但不一定是庫）提供「綁定」時，被解釋程序通過這些綁定有效地與其使用的程序相關聯。JNI（Java Native Interface）是此種程序的一個例子；以這種方式訪問​​的庫與調用它們的 Java 程序動態鏈接。

因此，如果這些程序是依據與 GPL 不兼容的許可證發布的，則情況就像以任何其他方式跟與 GPL 不兼容的庫鏈接。這意味著：

1. 如果您正在編寫代碼並將其依據 GPL 發布，您可以聲明一個 明確例外 （ explicit exception ） ，允許將其鏈接到與 GPL 不兼容的程序。
2. 如果您依據 GPL 編寫並發布程序，並且專門設計了與這些程序配合使用的功能，人們可以將其作為 隱性例外 （ implicit exception ） ，允許它們與這些程序進行鏈接。但是，如果這只是你的打算的話，最好明確地這麼說。

您不能把別人遵循 GPL 的代碼用於這種方式，或者添加這樣的例外。只有該代碼的版權所有者才能添加例外。

6.15 如果我將一個模塊添加到遵循 GPL 的程序中，我必須使用 GPL 作為我的模塊的許可證嗎？

GPL 規定，整個結合後的程序必須依據 GPL 發布。所以你的模塊必須可以依據 GPL 進行使用。

但是，您可以提供使用您代碼的額外授權。如果您願意，您可以依據比 GPL 更為寬鬆但與 GPL 兼容的許可證發布模塊。許可證列表頁面提供了與 GPL 兼容許可證的部分列表。

6.16 什麼時候程序和插件會被認為是單一的結合程序？

這取決於主程序如何調用其插件。如果主程序使用 fork 和 exec 來調用插件，並通過共享複雜的數據結構或來回傳送複雜的數據結構來建立 密切通信 （ intimate communication ） ，可以使它們成為一個單一的結合程序。如果主程序使用簡單的 fork 和 exec 來調用插件並且不建立它們之間的密切通信，插件被認為是一個單獨的程序。

如果主程序動態地鏈接插件，並且它們彼此進行函數調用並共享數據結構，我們相信它們形成了一個單一的結合程序，它必須被視為主程序和插件的擴展。如果主程序動態地鏈接插件，但是它們之間的通信僅限於使用某些選項調用插件的「main」功能，並等待它返回，這是一種 臨界案例 （ borderline case ） 。

使用共享內存與複雜數據結構進行通信幾乎等同於動態鏈接。

6.17 如果我寫了一個用於遵循 GPL 程序的插件，那麼對可用於分發我的插件的許可證有什麼要求？

請參閱 「6.16 什麼時候程序和插件會被認為是單一的結合程序 ？」以確定插件和主程序是否被視為單個結合程序，以及何時將其視為單獨的作品。

如果主程序和插件是單個結合程序，則這意味著您必須依據 GPL 或與 GPL 兼容的自由軟體許可證授權插件，並以符合 GPL 的方式將源代碼進行分發。與其插件分開的主程序對插件沒有要求。

6.18 在為非自由程序編寫插件時，可以應用 GPL 許可證嗎？

請參閱 「6.16 什麼時候程序和插件會被認為是單一的結合程序？」以確定插件和主程序是否被視為單個結合程序，以及何時被視為單獨的程序。

如果它們組成單一的結合程序，這意味著遵循 GPL 的插件與非自由主程序的結合將違反 GPL。但是，您可以通過向插件的許可證添加例外聲明來解決該法律問題，並允許將其與非自由主程序鏈接。

另請參閱正在編寫的使用非自由庫的自由軟體的問題。

6.19 我可以發布一個旨在載入遵循 GPL 的插件的非自由程序嗎？

請參閱 「6.16 什麼時候程序和插件會被認為是單一的結合程序？」以確定插件和主程序是否被視為單個結合程序，以及何時被視為單獨的程序。

如果它們組成單一的結合程序，則主程序必須依據 GPL 或與 GPL 兼容的自由軟體許可證發布，並且當主程序為了與這些插件一起使用而被分發時，必須遵循 GPL 的條款。

然而，如果它們是單獨的作品，則插件的許可證對主程序沒有要求。

另請參閱正在編寫的使用非自由庫的自由軟體的問題。

6.20 我想將遵循 GPL 的軟體納入我的專有系統。我只依據 GPL 給予我的許可權來使用該軟體。我可以這樣做嗎？（同 5.6）

您不能將遵循 GPL 的軟體納入專有系統。GPL 的目標是授予每個人複製、再分發、理解和修改程序的自由。如果您可以將遵循 GPL 的軟體整合到非自由系統中，則可能會使遵循 GPL 的軟體不再是自由軟體。

包含遵循 GPL 程序的系統是該 GPL 程序的擴展版本。GPL 規定，如果它最終發布的話，任何擴展版本的程序必須依據 GPL 發布。這有兩個原因：確保獲得軟體的用戶獲得自己應該擁有的自由，並鼓勵人們回饋他們所做的改進。

但是，在許多情況下，您可以將遵循 GPL 的軟體與專有系統一起分發。要有效地做到這一點，您必須確保自由和非自由程序之間的通信 保持一定距離 （ arms length ） ，而不是將它們有效地結合成一個程序。

這種情況與「納入」遵循 GPL 的軟體之間的區別，是一部分實質和一部分形式的問題。實質上是這樣的：如果兩個程序結合起來，使它們成為一個程序的兩個部分，那麼您不能將它們視為兩個單獨的程序。所以整個作品必須遵循 GPL。

如果這兩個程序保持良好的分離，就像編譯器和內核，或者像編輯器和shell一樣，那麼您可以將它們視為兩個單獨的程序，但是您必須恰當執行。這個問題只是一個形式問題：您如何描述您在做什麼。為什麼我們關心這個？因為我們想確保用戶清楚地了解軟體集合中遵循 GPL 的軟體的自由狀態。

如果人們分發遵循 GPL 的軟體，將其稱為系統（用戶已知其中一部分為專有軟體）的「一部分」，用戶可能不確定其對遵循GPL的軟體所擁有的權利。但是如果他們知道他們收到的是一個自由程序加上另外一個程序，那麼他們的權利就會很清楚。

6.21 我想將遵循 GPL 的軟體納入我的專有系統。我是否可以通過在 GPL 覆蓋的部分和專有部分之間，放置一個遵循與 GPL 兼容的寬鬆許可證（如 X11 許可證）的 「封裝」 （ wrapper ） 模塊來實現？

不可以，X11 許可證與 GPL 兼容，因此您可以向遵循 GPL 的程序添加一個模塊，並讓其遵循 X11 許可證。但是，如果要將它們整合到一個更大的程序中，那麼這個整體將包含 GPL 覆蓋的部分，所以它必須在 GNU GPL 下作為一個整體獲得許可。

專有模塊 A 僅通過遵循 X11 許可證的模塊 B 與遵循 GPL 的模塊 C 通信，該事實在法律上是無關緊要的；重要的是模塊 C 包含在整體作品中。

6.22 我可以編寫使用非自由庫的自由軟體嗎？

如果您這樣做，您的程序將無法在一個自由的環境中完全使用。如果您的程序依賴於一個非自由庫來做某件工作，那麼在自由軟體世界裡就不能做這個工作。如果這依賴於一個非自由庫來運行，它不能是自由操作系統（例如 GNU）的一部分；這完全成為了自由軟體世界裡的禁區。

所以請考慮：你可以找到一種方法來完成這項工作，而不使用這個庫嗎？你可以為該庫編寫一個自由軟體替代選擇嗎？

如果程序已經使用非自由庫編寫，那麼改變決定也許已經太晚了。您也可以按照目前狀態來發布程序，而不是不發布。但是請在 README 文件中提到，對非自由庫的需求是一個缺點，並建議更改程序以便在沒有非自由庫的情況下執行相同的工作。請建議任何想要在程序上進行大量進一步工作的人首先將其從依賴非自由庫中解脫出來。

請注意，將某些非自由庫與遵循 GPL 的自由軟體相結合也可能存在法律問題。有關更多信息，請參閱有關 GPL 軟體與和其不兼容庫的問題。

6.23 我可以將遵循 GPL 的程序與專有系統庫鏈接嗎？

每個版本的 GPL 相對於其 左版 （ copyleft ） 都有一個例外，通常稱為系統庫例外。如果您要使用的與 GPL 不兼容的庫符合系統庫的標準，則使用它們不需要做特別的工作；分發整個程序的源代碼的要求不包括那些庫，即使您分發包含它們的鏈接可執行文件。

作為 「系統庫」 （ system library ） 的標準在不同版本的 GPL 之間有所不同。GPL v3 在第 1 節中明確定義「系統庫」，將其從 「相應源代碼」 （ Corresponding Source ） 的定義中排除。GPL v2 在第 3 部分的末尾進行，處理這個問題略有不同。

6.24 如果我在遵循 GPL 的軟體中使用了與 GPL 不兼容的庫，會出現什麼法律問題？

如果您希望程序與未被系統庫例外所涵蓋的庫鏈接，則需要提供許可來執行此操作。以下是您可以使用的兩個許可證通知示例；一個用於 GPL v3，另一個用於 GPL v2。在這兩種情況下，您應該將此文本放在您授予此許可權的每個文件中。

只有該程序的版權持有人才能合法地按照這些條款發布其軟體。如果您自己編寫了整個程序，假設您的僱主或學校沒有聲明版權，您就是版權所有者，因此您可以授權該例外。但是，如果您想在代碼中使用其他作者的其他遵循GPL的程序的一部分，那麼您無法將例外授權給他們。您必須獲得這些程序的版權所有者的批准。

當其他人修改程序時，他們不需要為他們的代碼設置同樣的例外——是否這樣做是他們自己的選擇。

如果您打算鏈接的庫不是自由軟體，請參閱使用非自由庫編寫自由軟體部分。

如果您使用 GPL v3，您可以通過在第 7 節下授予額外許可權來實現此目標。以下許可證通知將會執行此操作。您必須使用適合您程序的文本替換括弧中的所有文本。如果不是每個人都可以為您打算鏈接的庫分發源代碼，則應該刪除大括弧中的文本；否則，只需刪除大括弧。

Copyright (C) [年份] [著作權人名稱]

本程序為自由軟體；您可以根據自由軟體基金會發布的 GNU GPL 許可證的條款再分發和/或修改它；無論是依據本許可證的版本3，或（根據您的選擇）任何更高版本。

本程序基於希望其有用的目標而分發，但不提供任何擔保；甚至也沒有適銷性或適用於特定用途的默示擔保。有關詳細信息，請參閱 GNU GPL 許可證。

您應該已經收到本程序以及 GNU GPL 許可證的副本；如果沒有，請參閱 http://www.gnu.org/licenses。

依據 GNU GPL v3 第7節的額外許可

如果您通過將[與庫的名稱]（或庫的修改版本）鏈接或結合來修改本程序，或任何被覆蓋的作品，其中包含被[庫許可證的名稱]的條款所覆蓋的部分，則該程序的許可人授予您額外許可來傳遞所產出的作品。{這種結合的非源代碼形式的相應源代碼應包括所使用的[庫名稱]部分的源代碼以及被覆蓋的作品的源代碼。}

如果您使用 GPL v2，您可以為許可證條款提供自己的例外。以下許可證通知將這樣做。同樣，您必須使用適合您程序的文本替換括弧中的所有文本。如果不是每個人都可以為您打算鏈接的庫分發源代碼，則應該刪除大括弧中的文本；否則，只需刪除大括弧。

Copyright (C) [年份] [著作權人名稱]

本程序為自由軟體；您可以根據自由軟體基金會發布的 GNU GPL 許可證的條款再分發和/或修改它；無論是依據許可證的 v2，或（根據您的選擇）任何更高版本。

本程序基於希望其有用的目標而分發，但不提供任何擔保；甚至也沒有適銷性或適用於特定用途的默示擔保。有關詳細信息，請參閱 GNU GPL 許可證。

您應該已經收到本程序以及 GNU GPL 許可證的副本；如果沒有，請參閱 http://www.gnu.org/licenses。

將[您的程序名稱]與其他模塊靜態或動態鏈接是以[您的程序名稱]為基礎構建結合作品。因此，GNU GPL 許可證的條款和條件將覆蓋整個結合作品。

另外，作為一個特殊例外，[您的程序名稱]的版權持有人可以讓您將[您的程序名稱]與依據 GNU LGPL 發布的自由程序或庫以及依據[庫的許可證名稱]標準發布的[庫名稱]中包含的代碼相結合（或具有相同許可證的此類代碼的修改版本）。您可以按照[您的程序名稱]所依據的 GNU GPL 的條款和其他有關代碼的許可證複製和分發此系統{前提是當 GNU GPL 要求分發源代碼時將其他代碼的源代碼包含在內}。

注意，對[您的程序名稱]做出修改版本的人沒有義務為其修改版本授予此特殊例外；是否這樣做是他們自己的選擇。GNU GPL 許可證允許發布一個沒有此例外的修改版本；該例外也使得發布一個帶有該例外的修改版本成為可能。

6.25 我正在使用 Microsoft Visual C ++（或 Visual Basic）編寫 Windows 應用程序，我將依據 GPL 發布它。依據GPL，是否允許將我的程序與 Visual C ++（或 Visual Basic）運行時庫動態鏈接？

您可以將您的程序鏈接到這些庫，並將編譯後的程序分發給其他程序。執行此操作時，運行時庫是 GPL v3 所定義的「系統庫」。這意味著您不需要擔心將庫的源代碼包含在程序的相應源代碼中。GPL v2 在第 3 節中提供了類似的例外。

您可能不會隨同您的程序以編譯後的 DLL 形式分發這些庫。為了防止不道德的分發者試圖將系統庫例外作為漏洞進行利用，GPL 表示，只有庫不與程序本身一起分發，庫才能被認定為系統庫。如果您隨同您的程序分發 DLL，則它們將不再符合此例外的資格；那麼遵守 GPL 的唯一方法就是提供它們的源代碼，而您無法做到。

可以編寫只在 Windows 上運行的自由程序，但這不是一個好主意。這些程序將被 Windows 「圍困」 （ trapped ） ，因此對自由軟體世界的貢獻為零。

6.26 我想修改遵循 GPL 的程序，並將它們與 Money Guzzler Inc. 的可移植性庫鏈接。我無法分發這些庫的源代碼，因此，任何想要更改這些版本的用戶都必須單獨獲取這些庫。為什麼 GPL 不允許這樣做？

有兩個原因。第一、一般性的原因。如果我們允許 A 公司製作一個專有文件，B 公司分發與該文件相關的遵循 GPL 的軟體，其效果等同於將 GPL 撕開一個大洞。對於保持 GPL 軟體各種修改和擴展的源代碼來說，這如同一張署名空白紙。

讓所有用戶能夠訪問源代碼是我們的主要目標之一，所以這個結果絕對是我​​們想要避免的。

更具體地說，根據我們對條款的理解，與 Money Guzzler 庫鏈接的程序版本不會是真正的自由軟體——它們不會附帶完整的讓用戶能夠更改和重新編譯程序的源代碼。

6.27 如果模塊 Q 的許可證具有與 GPL 不兼容的要求，但是只有當 Q 自身分發時，而不是在較大程序中包含 Q 時，該要求才適用，是否可以使得該許可證與 GPL 兼容？可以將 Q 與遵循 GPL 的程序結合使用嗎？

如果程序 P 依據 GPL 被發布，這意味著「任何和所有部分」都可以依據 GPL 進行使用。如果您集成了模塊 Q，並依據 GPL 發布結合程序 P + Q，則表示可以依據 GPL 使用 P + Q 的任何部分。P + Q 的一部分是 Q，所以依據 GPL 發布 P + Q 意味著，Q 的任何部分可以依據 GPL 進行使用。換句話說，依據 GPL 獲得 P + Q 的用戶可以刪除 P，所以 Q 仍然遵循 GPL。

如果模塊 Q 的許可證允許您授予該許可，則其與 GPL 兼容。否則，它不與 GPL 兼容。

如果 Q 的許可證在不明確的條件下表示，您必須在自己再分發 Q 時做某些事情（與 GPL 不兼容），那麼不允許您依據 GPL 分發Q。因此，您也不能依據 GPL 發布 P + Q。所以您不能將 P 與 Q 進行鏈接或結合。

6.28 在面向對象的語言（如 Java）中，如果我在不修改的情況下使用遵循 GPL 的類，並對其進行子類化，GPL 會以什麼方式影響較大的程序？

子類化將會創建衍生作品。因此，當您創建遵循 GPL 的類的子類時，GPL 的條款會影響整個程序。

6.29 分發一個意圖鏈接到 Linux 內核的非自由驅動程序會違反 GPL 嗎？

Linux（GNU / Linux 操作系統中的內核）依據 GNU GPL v2 進行分發。分發一個意圖鏈接 Linux 的非自由驅動程序違反 GPL 嗎？

是的，這是一種違規行為，因為這樣做形成了更大的結合作品。用戶期望把這些片段放在一起的事實並不會改變任何事情。

在代碼實體部分擁有版權的 Linux 的每個貢獻者都可以執行 GPL，我們鼓勵他們對那些分發非自由 Linux 驅動程序的人採取行動。

6.30 如何允許在受控介面下將專有模塊與我的 GPL 庫鏈接起來？

在聲明該文件依據 GNU GPL 進行分發的文本末尾，將以下文本添加到軟體包中每個文件的許可證通知中：

將 ABC 與其他模塊靜態或動態鏈接是基於 ABC 創建結合作品。因此，GNU GPL 許可證的條款和條件將覆蓋整個結合作品。

作為一個特殊的例外，ABC 的版權所有者可以將 ABC 程序與自由軟體程序或依據 GNU LGPL 發布的庫以及通過 ABCDEF 界面與 ABC 通信的獨立模塊相結合。您可以根據 ABC 的 GNU GPL 條款和其他代碼的許可證複製和分發此系統，前提是您在 GNU GPL 需要分發源代碼時提供該代碼的源代碼，並且您沒有修改 ABCDEF 界面。

請注意，製作 ABC 修改版本的人沒有義務為其修改版本授予此特殊例外；是否這樣做是他們自己的選擇。GNU GPL 許可證允許發布不含此例外的修改版本；此例外也使得發布一個帶有該例外的修改版本成為可能。如果您修改了 ABCDEF 界面，此例外不適用於您修改的 ABC 版本，並且您必須在分發修改後的版本時刪除此例外。

此例外是依據 GNU GPL 許可證第3版（「GPL v3」）第7節的額外許可權。

此例外允許通過指定介面（「ABCDEF」）與遵循不同許可證的模塊進行鏈接，同時確保用戶仍然會按照 GPL 通常的方式接收源代碼。

只有該程序的版權持有者才能合法授權此例外。如果您自己編寫了整個程序，假設您的僱主或學校沒有聲明版權，您就是版權所有者，因此您可以授權該例外。但是，如果您想在代碼中使用其他作者的其他遵循 GPL 程序的一部分，那麼您無法對他們的例外進行授權。您必須獲得這些程序的版權所有者的批准。

6.31 考慮這種情況：1）X 發布遵循 GPL 的項目的 V1 版本。2）基於對 V1 的修改和新代碼開發，Y 對 V2 的改進做出貢獻。3）X 想將 V2 轉換為非 GPL 許可證。X 需要 Y 的許可嗎？

需要。Y 需要依據 GNU GPL 發布其版本，因為它基於 X 的版本 V1。沒有任何要求規定 Y 為其代碼適用任何其他許可。因此，X 必須獲得 Y 的許可才能依據另一個許可證發布該代碼。

6.32 我已經編寫了一個與許多不同組件鏈接的應用程序，它們具有不同的許可證。我對我的程序有什麼許可要求感到很困惑。您能告訴我可以使用哪些許可證嗎？

為了回答這個問題，我們需要看一下你的程序使用的每個組件的列表，該組件的許可證和一個簡短的（幾句話應該足夠）說明你的庫如何使用該組件的描述。兩個例子是：

• 為了讓我的軟體工作，它必須鏈接到遵循 LGPL 的 FOO 庫。
• 我的軟體進行系統調用（使用我建立的命令行）來運行 BAR 程序，該程序遵循 GPL，「具有允許與 QUUX 鏈接的特殊例外」。

6.33 可以在依據與 GPL 不兼容的許可證進行許可的文檔中使用遵循 GPL 的源代碼片段嗎？

如果片段足夠小，依據「合理使用」或類似的法律，您可以將它們納入其中，那麼可以。否則，不可以。

譯者介紹：薛亮，集慧智佳知識產權諮詢公司高級諮詢師，擅長專利檢索、專利分析、競爭對手跟蹤、FTO 分析、開源軟體知識產權風險分析，致力於為互聯網企業、高科技公司提供知識產權諮詢服務。

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive