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

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

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

3、在您的程序中使用 GNU 許可證

3.1 如何從 (L)GPLv2 升級到 (L)GPLv3？

首先，在您的軟體包中包含新版本的許可證。如果您在項目中使用 LGPL v3，請確保一同包含了 GPL v3 和 LGPL v3 的副本，因為 LGPL v3 現在被寫成在 GPL v3 基礎上的一系列附加許可。

其次，將所有現有的 v2 許可證 通知 （ notice ） （通常位於每個文件的頂部）替換為「如何使用 GNU 許可證」上新的推薦文本。它更加面向未來，因為它不再包括 FSF 的郵政地址。

當然，任何涉及軟體包許可證的描述性的文本（如在 README中）也應該被適當更新。

3.2 您能一步一步地指導我如何將GPL應用到我的程序嗎？

請參閱 GPL 說明書頁面。

3.3 為什麼我要使用 GNU GPL，而不是其他自由軟體許可證？（同 1.3）

使用 GNU GPL 將要求所有發布的改進版本都是自由軟體。這意味著您可以避免與您自己作品的專有修改版本進行競爭的風險。不過，在某些特殊情況下，最好使用一個更寬鬆的許可證。

3.4 為什麼 GPL 要求程序的每個副本必須包含 GPL 許可證副本？（同 2.14）

作品包含許可證副本至關重要，因此獲得程序副本的每個人都可以知道他們的權利是什麼。

包括一個指向許可證的 URL，而不是將許可證本身包含在內，這是一種看起來很誘人的做法。但是您不能確定該 URL 在五年或十年後仍然有效。二十年後，我們今天所知道的 URL 們可能已不復存在。

不管網路將發生什麼樣的變化，確保擁有該程序副本的人員能夠繼續看到 GPL 許可證的唯一方法是，將許可證的副本包含在該程序中。

3.5 只需將 GNU GPL 的副本放在我的存儲庫中就可以了嗎？

僅將 GNU GPL 的副本放在存儲庫中的文件中，並不能明確地聲明可以依據 GNU GPL 使用同一存儲庫中的代碼。如果沒有這樣的聲明，並不能完全清楚地表明許可證中的許可權真的可以適用於任何特定的源文件。一個明確的聲明將消除所有的疑問。

文件僅包含許可證文本，而沒有一個聲明規定某些其他文件被該許可證覆蓋，類似於文件包含一個其他任何地方都不會調用的子常式。但這種相似之處並不完美：律師和法院可能應用常識得出結論，因為您希望以 GPL 方式許可代碼，所以您必定要將GNU GPL 的副本放在那裡。或許律師和法院不會這樣做。但為什麼要留下不確定性呢？

每個源文件中都應該包括聲明文本。只要能夠伴隨代碼，程序的 README 文件中的清晰聲明從法律上來說就足夠了，但是它們很容易分離。所以，為什麼要給您的代碼許可證帶來不確定性的風險呢？

這與 GNU GPL 的具體內容無關。對於任何自由許可證來說都是正確的。

3.6 為什麼要在每個源文件中放置許可證 通知 （ notice ） ？

您應該在每個源文件的起始處放置通知，說明它所攜帶的許可證，以避免代碼與其許可證被斷開的風險。如果您存儲庫的 README 文件聲明源文件遵循 GNU GPL，如果有人將該文件複製到另一個程序，會發生什麼呢？ 其他上下文可能無法表明該文件的許可證是什麼。它似乎有一些其他許可證，或根本沒有許可證（這將使代碼變成非自由軟體）。

在每個源文件的開始添加版權聲明和許可證通知很容易，造成這種混亂的可能性不大。

這與 GNU GPL 的具體內容無關。對於任何自由許可證來說都是正確的。

3.7 如果作品不是很長，那該怎麼辦？（同 2.15）

如果整個軟體包中只有很少的代碼——我們使用的基準是不到 300 行，那麼您可以使用一個寬鬆的許可證，而不是像 GNU GPL 這樣的左版許可證（除非代碼特別重要）。我們建議這種情況使用 Apache 許可證 2.0。

3.8 為了節省空間，我是否可以省略 GPL 的引言部分，或者省略如何在自己的程序上使用 GPL 的 指導 （ instructions ） 部分嗎？（同 2.21）

引言和指導是 GNU GPL 的組成部分，不能省略。事實上，GPL 是受版權保護的，其許可證規定只能逐字複製整個 GPL。（您可以使用法律條款製作另一個許可證，但該許可證不再是 GNU GPL。）

引言和指導部分共約 1000 字，不到 GPL 總文字數量的 1/5。除非軟體包本身很小，否則引言和指導不會對軟體包的大小產生大幅度的改變。在軟體包很小的情況下，您可以使用一個簡單的 全權 （ all-permissive ） 許可證，而不是 GNU GPL。

3.9 如何獲得我的程序的版權，以便依據 GPL 發布？

根據 《伯爾尼公約》 （ Berne Convention ） ，所有書寫成文的內容都將自動受版權保護。所以你沒有必要做任何事情來「獲得」你所寫代碼的版權——只要沒有其他人聲稱擁有你的作品。

不過，在美國註冊版權是一個很好的主意。這將給你在美國應對侵權者帶來更多的影響力。

其他人可能聲稱擁有版權的情況是，如果您是僱員或學生；那麼僱主或學校可能會聲稱你為他們做了工作，並且版權屬於他們。他們是否存在有效的權利主張將取決於你所居住地方的法律，以及你的僱傭合同和你所做的工作。如果有任何疑問，最好諮詢律師。

如果您認為僱主或學校可能會提出權利主張，您可以通過獲得公司或學校適當授權的官員簽署的版權免責聲明來明確解決該問題。（您的直接上司或教授通常無權簽署此免責聲明。）

3.10 如果我的學校想將我自己的程序應用到學校的專有軟體產品，我該怎麼辦？

現在許多大學試圖通過限制他們所開發的知識和信息的使用來籌集資金，其實際上與商業業務有所不同。 （參見刊載於 2000 年 3 月 《大西洋月刊》 （ Atlantic Monthly ） 的 《受縛的大學》 （ The Kept University ） ，該文章對這個問題及其影響進行了一般性的討論。）

如果您在某種程度上認為您的學校可能拒絕允許您的程序作為自由軟體發布，最好儘早提出這個問題。程序越接近於有用的作品，行政部門越有動機從你手裡拿回該程序，並在沒有你的情況下完成它。在更早的階段，你有更多的影響力。

所以我們建議你在程序只進行一半的時候接觸他們，說：「如果你同意將它作為自由軟體發布，我會完成它。」不要以為這是虛張聲勢。要取得勝利，你必須有勇氣說：「我的程序如果不能成為自由軟體，我寧願不把它寫出來。」

3.11 我想發布一個我依據 GNU GPL 編寫的程序，但是我想在非自由程序中使用相同的代碼。

發布一個非自由程序總是有道德上的污點，但從法律上來說沒有任何障礙阻止你這樣做。如果您是代碼的版權所有者，您可以在不同時間以各種不同的非獨佔許可證發布。

3.12 依據 GPL 分發的程序的開發人員是否可以將其授權給另一方專用？

不可以，因為公眾已經有權利使用遵循 GPL 的該程序，這個權利是不能撤銷的。

3.13 美國政府可以依據 GNU GPL 發布一個程序嗎？

如果這個程序是由美國聯邦政府僱員在僱用過程中編寫的，那麼它是處於公有領域，這意味著它不受版權保護。由於GNU GPL是基於版權的許可證，所以這樣的程序不能依據 GNU GPL 發布。（它仍然可以是自由軟體，公有領域的程序是自由軟體。）

不過，當美國聯邦政府機構使用承包商來開發軟體時，那就是不同的情況。合同可以要求承包商依據 GNU GPL 進行發布（GNU Ada 是以這種方式開發的）。或者合同可以將版權 分配 （ assign ） 給政府機構，然後政府機構可以依據 GNU GPL 發布該軟體。

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

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

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

3.15 程序里為什麼要說「GPL 的版本 3 或任何更新的版本」？

隨著時間的推移，我們會不斷更改 GPL——有時要澄清一下，有時允許以前不允許的某些用途，有時會收緊要求。（最後兩次更改是在 2007 年和 1991 年。）當我們更新 GPL 時，在每個程序中使用這個「間接指針」可以讓我們有可能針對整個 GNU 軟體集合更改分發條款。

如果每個程序缺少間接指針，我們將被迫與許多版權持有者進行長時間的討論，這在事實上是不可能實現的。在實踐中，為 GNU 軟體制定統一分發條款的機會將為零。

假設一個程序里說「GPL 的版本 3 或任何更新的版本」，並且一個新版本的 GPL 被發布。如果新的 GPL 版本提供了額外的許可，那麼該許可權將立即提供給程序的所有用戶。但是，如果新的 GPL 版本要求更嚴格，則不會對使用當前版本的程序形成限制，因為該程序仍然可以依據 GPL 版本 3 進行使用。當程序里說「GPL 的版本 3 或任何更新的版本」，用戶將被永遠允許使用它，甚至可以依據 GPL 版本 3 的條款進行更改，即使在後續版本的 GPL 可用後也是如此。

如果GPL的新版本中更嚴格的要求不需要被現有軟體遵守，那麼它還有用嗎？一旦 GPL 版本 4 可用，大多數遵循 GPL 的程序的開發人員將發布其程序的後續版本，闡明其採用「GPL 的版本 4 或任何更新的版本」。那麼用戶將不得不遵循 GPL 版本 4 中更嚴格的要求，以便使用程序的後續版本。

然而，開發人員沒有義務這樣做；如果這是他們的偏好，開發人員可以繼續被允許使用以前版本的 GPL。

3.16 使用一個聲明某個程序只能依據最新版本的 GNU GPL 進行使用的許可證是個好主意嗎？

您不應該這樣做，原因是它可能會導致未來某一天自動撤回用戶以前擁有的一些許可權。

假設一個程序是在 2000 年依據「最新的 GPL 版本」進行發布。當時，人們可以依據 GPL 版本 2 使用它。在 2007 年發布 GPL 版本 3 的那一天，每個人都將被迫不得不依據 GPL 版本 3 使用該程序。

有些用戶甚至可能不知道 GPL 版本 3——但是他們將被要求使用它。他們可能會無意中違反該程序的許可證，只因為他們沒有得到 GPL 版本 3發布的消息。這不是個對待別人的好方法。

除非因為違規，我們認為收回已經授予的許可權是錯誤的做法。如果您的自由可以被撤銷，那麼這不是真正的自由。因此，如果您獲得遵循某個版本許可證的某個版本程序的副本，則應始終具有該版本許可證授予的許可權。依據「GPL 的版本 N 或任何更新的版本」進行發布維護了該原則。

3.17 有沒有一些方法可以讓使用我的程序的人們得到的輸出物遵循 GPL？例如，如果我的程序用於開發硬體設計，我可以要求這些設計必須是自由的嗎？

一般來說，這在法律上是不可能的；針對人們通過使用您的程序獲取數據形成的輸出物如何使用，版權法並沒有賦予您任何發言權。如果用戶使用您的程序輸入或轉換自己的數據，輸出物的版權屬於他，而不是您。更一般來說，當程序將其輸入物轉換成其他形式時，輸出物的版權狀態將繼承其得以生成的輸入物的版權狀態。

所以您對輸出物的使用擁有發言權的唯一方式是輸出物的實質部分（或多或少）是從您程序的文本中複製出來。例如，如果我們在這種具體情況下沒有例外，那麼Bison的一部分輸出物（參見問題 5.2）將被 GNU GPL 所涵蓋。

所以，即使沒有技術原因，您也可以人為製作一個程序，將某些文本複製到其輸出物中。但是，如果複製的文本沒有實際用途，用戶可以簡單地從輸出物中刪除該文本，並且僅使用其餘的內容。那麼他就不必滿足重新分發所複製文本的條件。

3.18 手冊為什麼不使用 GPL 許可證？（同 1.7）

手冊也可以使用 GPL 許可證，但對於手冊來說，最好使用 GFDL（自由文本授權，GNU Free Documentation License）許可證。

GPL 是為軟體程序設計的，它包含許多複雜的條款，對於程序來說至關重要；但對於圖書或手冊來說，這將是麻煩和不必要的。例如，任何人如果（以 GPL）出版紙質圖書，就要麼必須為每份印刷版本配置該圖書的機器可讀形式「源代碼」，或提供書面文件，表明將稍後發送「源代碼」。

同時，GFDL 中包含了幫助免費手冊的出版商從銷售副本中獲利的條款，例如，出售封面文字。 背書 （ Endorsements ） 部分的特殊規則使得 GFDL 可以作為官方標準。修改版本的手冊是被允許的，但該修改版本不能被標記為「該標準」。

使用 GFDL，我們允許對手冊中涵蓋其技術主題的文本進行修改。能夠修改技術部分非常重要，因為修改程序的人理所當然地要去修改對應的文檔。人們有這樣做的自由，它是一種道德責任。我們的手冊還包括闡述我們對自由軟體政治立場的部分。我們將它們標記為 「不變數」 （ invariant ） ，使得它們不被更改或刪除。 GFDL 中也為這些「不變部分」做出了規定。

3.19 GPL 如何適用於字體？

字體許可是一個複雜的問題，需要認真考慮。以下許可證例外是試驗性的，但被批准用於一般用途。我們歡迎關於這個問題的建議——請參閱這個解釋性文章，並寫郵件到 licensing@gnu.org 。

要使用此例外，請將該文本添加到軟體包中的每個文件的許可證通知中（儘可能），在文本末尾說明該文件依據 GNU GPL 分發：

作為一個特殊的例外，如果您創建一個使用此字體的文檔，並將該字體或該字體未更改的部分嵌入到文檔中，則此字體本身不會導致生成的文檔被 GNU 通用公共許可證 （ GNU General Public License ） 覆蓋。然而，這個例外不會使文檔可能被 GNU 通用公共許可證涵蓋的任何其他原因無效。如果您修改此字體，您可以將此例外擴展到您的字體版本，但是您沒有義務這樣做。如果您不想這樣做，請從您的版本中刪除此例外聲明。

3.20 我正在編寫一個網站維護系統（有人稱之為「內容管理系統」）或者是其他一些從模板生成網頁的應用程序。我應該為這些模板使用什麼許可證？

模板很小，不值得使用 左版 （ copyleft ） 來保護它們。在小作品上使用左版通常是無害的，但模板是一種特殊情況，因為它們與應用程序用戶提供的數據結合使用，並且其組合被分發。因此，我們建議您以簡單的許可條款許可您的模板。

一些模板調用 JavaScript 函數。由於 JavaScript 通常是不一般的作品，因此它值得用左版保護。由於模板與用戶數據相結合，因此模板 + 用戶數據 + JavaScript 可能被版權法看作是一個作品。需要在 JavaScript（受左版保護）和用戶代碼（通常遵循不兼容的條款）之間劃清界限。

以下是執行此操作的 JavaScript 代碼的一種例外：

作為 GPL 的一個特殊例外，僅對此代碼進行函數調用並且為此目的通過引用將其包括在內的 HTML 文件，將被視為版權法意義下的單獨作品。此外，此代碼的版權所有者可以讓您將該代碼與依據 GNU LGPL 發布的自由軟體庫相結合。您可以按照此代碼所遵循的 GNU GPL 條款以及此庫所遵循的 LGPL 條款複製和分發這樣一個系統。如果您修改此代碼，則可以將此例外擴展到您的代碼版本，但是您沒有義務這樣做。如果您不想這樣做，請從您的版本中刪除此例外聲明。

3.21 我可以發布一個使用非自由工具開發的遵循 GPL 的程序嗎？

您使用什麼程序來編輯、編譯、研究、記錄源代碼，通常對於該源代碼的許可問題沒有任何影響。

但是，如果將非自由庫與源代碼鏈接，那麼它就是一個您需要進行處理的問題。它不阻礙依據GPL發布源代碼，但是如果這些庫不符合 「系統庫」 （ system library ） 例外情況，那麼您應該附加一個明確的通知，允許您的程序與它們進行鏈接。有關使用 GPL 不兼容庫的 FAQ 條目提供了如何執行此操作的更多信息。

3.22 我使用公鑰加密來對我的代碼進行簽名，以確保其真實性。GPL v3 是否強制要求我發布我的私人簽名密鑰？

否。只有在您將遵循 GPL 的軟體傳遞給用戶產品之中，您才需要發布簽名密鑰，並且其硬體會在功能啟動之前檢查該軟體來獲得有效的密碼簽名。在這種具體情況下，您將被要求提供密鑰給任何擁有該設備的人員，使其按照要求在設備上簽名並安裝修改後的軟體，以便其運行。如果具體每個設備使用不同的密鑰，那麼您只需要為每個購買者提供相應的密鑰。

3.23 GPL v3 是否要求投票人能夠修改在投票機中運行的軟體？（同 2.41）

不要求。企業分發包含遵循 GPL v3 軟體的設備，最多只需要為擁有目標代碼副本的人提供軟體的源代碼和安裝信息。使用投票機（如同任何其他信息亭一樣）的選民不能擁有它，甚至不能暫時擁有，所以選民也不能擁有二進位軟體。

不過，請注意，投票是一個非常特殊的情況。僅僅因為計算機中的軟體是自由軟體，並不意味著您可以信任計算機，並進行投票。我們認為電腦不值得信任，不能被用作投票。投票應在紙上進行。

3.24 GPL v3 中的擔保和免責聲明似乎是依據美國法律的。我可以將自己的免責聲明添加到我自己的代碼中嗎？

可以。GPL v3 第 7 節允許您添加自己的免責聲明，具體來說是 7（a）。

3.25 我的程序具有非視覺性的互動式用戶界面。如何遵守 GPL v3 中的 適當法律聲明 （ Appropriate Legal Notices ） 要求？

所有您需要做的是確保適當法律聲明對於您界面中的用戶來說唾手可得。例如，如果您已經編寫了一個音頻介面，您可以包括一個大聲朗讀該聲明的命令。

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