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

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

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

1、關於 GNU 項目、自由軟體基金會（FSF）及其許可證的基本問題

1.1 「GPL」 代表什麼意思？

「GPL」 代表「 通用公共許可證 （ General Public License ） 」。 最常見的此類許可證是 GNU 通用公共許可證，簡稱 GNU GPL。 如果人們能夠自然而然地將其理解為 GNU GPL，可以進一步縮短為「GPL」。

1.2 自由軟體是否意味著必須使用 GPL？

根本不是的，還有許多其他自由軟體許可證。我們有一個不完整的列表。任何為用戶提供特定自由的許可證都是自由軟體許可證。

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

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

1.4 所有 GNU 軟體都使用 GNU GPL 作為其許可證嗎？

大多數 GNU 軟體包都使用 GNU GPL，但是有一些 GNU 程序（以及程序的一部分）使用更寬鬆的許可證，例如 LGPL（ 較寬鬆公共許可證 （ Lesser GPL ） ）。我們這樣做是基於戰略考慮。

1.5 如果一個程序使用 GPL 許可證，是否會使其成為 GNU 軟體？

任何人都可以依據 GNU GPL 發布一個程序，但並不能使其成為 GNU 軟體包。

讓程序成為 GNU 軟體包意味著將其明確地貢獻給 GNU 項目。當程序的開發人員和 GNU 項目都同意這樣做時，才會發生這種情況。如果您有興趣向 GNU 項目貢獻程序，請寫信至 maintainers@gnu.org 。

1.6 我可以將 GPL 應用於軟體以外的其他作品嗎？

您可以將 GPL 應用於任何類型的作品，只需明確該作品的「源代碼」構成即可。 GPL 將「源代碼」定義為作品的首選形式，以便在其中進行修改。

不過，對於手冊和教科書，或更一般地，任何旨在教授某個主題的作品，我們建議使用 GFDL，而非 GPL。

1.7 手冊為什麼不使用 GPL 許可證？

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

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

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

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

1.8 GPL 被翻譯成其他語言了嗎？

將 GPL 翻譯成英文以外的語言將是有用的。人們甚至進行了翻譯，並將文本發送給我們。但我們不敢將翻譯文本批准為正式有效。其中的風險如此之大，以至於我們不敢接受。

法律文件在某種程度上就像一個程序。翻譯它就像將程序從一種語言和操作系統轉換到另一種語言。只有同時熟練使用這兩種語言的律師才能做到這一點——即便如此，也有引入錯誤的風險。

如果我們正式批准 GPL 的翻譯文本，我們將不得不給予所有人許可，讓他們可以去做翻譯文本規定可以做的任何事情。如果這是一個完全準確的翻譯，那沒關係。但如果翻譯錯誤，後果可能是我們無法解決的災難。

如果一個程序有 bug，我們可以發布一個新的版本，最終舊版本將會逐漸消失。但是，一旦我們給予每個人去根據特定翻譯文本行事的許可，如果我們稍後發現它有一個錯誤，我們無法收回該許可權。

樂意提供幫助的人有時會為我們做翻譯工作。如果問題是要找人做這個工作的話，那問題就解決了。但實際的問題是錯誤的風險，做翻譯工作不能避免風險。我們無法授權非律師撰寫的翻譯文本。

因此，目前我們並不認可GPL的翻譯文本是全球有效和具有約束力的。相反，我們正在做兩件事情：

• 將非正式的翻譯指引給人們。這意味著我們允許人們進行GPL的翻譯，但是我們不認可翻譯文本具有法律效力和約束力。
  未經批准的翻譯文本沒有法律效力，應該如此明確地表述。翻譯文本應標明如下：

This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
本 GPL 翻譯文本是非正式的，沒有被自由軟體基金會（FSF）正式批准為有效。若要完全確定何種行為被允許，請參閱原始 GPL（英文）。

但未經批准的翻譯文本可以作為如何理解英文 GPL 的參考。對於許多用戶來說，這就足夠了。不過，在商業活動中使用 GNU 軟體的企業，以及進行公共 ftp 發行的人員，需要去核查實際的英文 GPL，以明確其允許的行為。

• 發布僅在單個國家/地區有效的翻譯文本。
  我們正在考慮發布僅在單個國家正式生效的翻譯文本。這樣一來，如果發現有錯誤，那麼錯誤將局限於這個國家，破壞力不會太大。
  即便是一個富有同情心和能力的律師來做翻譯，仍然需要相當多的專門知識和努力，所以我們不能很快答應任何這樣的翻譯。

1.9 為什麼有一些 GNU 庫依據普通 GPL 而不是 LGPL 來發布？

對於任何特定庫使用 LGPL 構成了自由軟體的倒退。這意味著我們部分放棄了捍衛用戶自由權利的努力，對基於 GPL 軟體所構建產品的分享要求也降低了。在它們自身而言，這是更糟糕的變化。

有時一個小範圍的倒退是很好的策略。某種情況下，使用 LGPL 的庫可能會帶來該庫的廣泛使用，從而進一步改善該庫，為自由軟體帶來更廣泛的支持，諸如此類。如果在相當大的程度上出現這種情況，這可能對自由軟體很有好處。但它發生的幾率有多少呢？我們只能推測。

在每個庫上用一段時間的 LGPL，看看它是否有幫助，如果 LGPL 沒有幫助，再將其更改為 GPL。這種做法聽起來很好，但卻是不可行的。一旦我們對特定庫使用了 LGPL，那就很難進行改變。因此，我們根據具體情況決定每個庫使用哪個許可證。對於我們如何判斷該問題，有一段很長的解釋。

1.10 誰有權力執行 GPL 許可證？

由於 GPL 是版權許可，軟體的版權所有者將是有權執行 GPL 的人。如果您發現違反 GPL 的行為，您應該向遵循GPL的該軟體的開發人員通報。他們是版權所有者，或與版權所有者有關。若要詳細了解如何報告 GPL 違規，請參閱「如果發現了可能違反 GPL 許可證的行為，我該怎麼辦？」

1.11 為什麼 FSF 要求為 FSF 擁有版權的程序做出貢獻的貢獻者將版權 分配 （ assign ） 給 FSF？如果我持有 GPL 程序的版權，我也應該這樣做嗎？如果是，怎麼做？

我們的律師告訴我們，為了最大限度地向法院要求違規者強制執行 GPL，我們應該讓程序的版權狀況儘可能簡單。為了做到這一點，我們要求每個貢獻者將貢獻部分的版權分配給 FSF，或者放棄對貢獻部分的版權要求。

我們也要求個人貢獻者從僱主那裡獲得版權放棄聲明（如果有的話），以確保僱主不會聲稱擁有這部分貢獻的版權。

當然，如果所有的貢獻者把他們的代碼放在公共領域，也就沒有用之來執行 GPL 許可證的版權了。所以我們鼓勵人們為大規模的代碼貢獻分配版權，只把小規模的修改放在公共領域。

如果您想要在您的程序中執行 GPL，遵循類似的策略可能是一個好主意。如果您需要更多信息，請聯繫 licensing@gnu.org。

1.12 我可以修改 GPL 並創建一個修改後的許可證嗎？

您可以製作GPL的修改版本，但這往往會產生實踐上的後果。

您可以在其他許可證中合法使用GPL條款（可能是修改過的），只要您以其他名稱來稱呼您的許可證，並且不包括 GPL 的 引言 （ preamble ） ，只要您對最後的使用說明進行了足夠多的修改，使其措辭明顯不同，沒有提到 GNU（儘管您描述的實際過程可能與其類似）。

如果您想在修改後的許可證中使用我們的引言，請寫信至 licensing@gnu.org，以獲得許可。我們需要查看實際的許可證要求，才能決定我們是否能夠批准它們。

雖然我們不會以這種方式對您修改許可證提出法律上的反對意見，但我們希望您三思而行，別去修改許可證。類似這些修改後的許可證幾乎肯定與 GNU GPL 不兼容，並且這種不兼容性阻礙了模塊之間的有用組合。

不同自由軟體許可證的擴散本身就是一個負擔。請使用 GPL v3 提供的 例外 （ exception ） 機制，而不是去修改 GPL。

1.13 為什麼你們決定將 GNU Affero GPL v3 作為一個單獨的許可證？

GPLv3 的早期草案在第 7 節中允許許可人在發布源代碼時添加一個類似 Affero 的要求。但是，一些開發和依賴自由軟體的公司認為這個要求太過繁重。他們希望避免使用遵循這個要求的代碼，並且對檢查代碼是否符合這個附加要求所帶來的管理成本表示擔憂。通過將 GNU Affero GPL v3 作為單獨的許可證發布，在該許可證以及 GPL v3 中允許遵循該許可證的代碼鏈接到彼此，我們完成了所有最初的目標，同時更容易確定哪些源代碼需要遵循發布要求。

（題圖：pycom.io）

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

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