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）要求？

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