關於 GNU GPL 第 2 版的常見問題

“GPL” 代表什麼？

“GPL” 代表“通用公共許可證”（General Public License）。最廣泛使用的此類許可證是 GNU 通用公共許可證，或簡稱 GNU GPL。當理解到 GNU GPL 是預期的許可證時，可以進一步縮短為 “GPL”。

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

完全不是—還有許多其他自由軟體許可證。我們有一個不完整的列表。任何提供使用者某些特定自由的許可證都是自由軟體許可證。

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

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

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

大多數 GNU 軟體套件使用 GNU GPL，但有一些 GNU 程式（和程式的一部分）使用更寬鬆的許可證，例如寬鬆 GPL。當我們這樣做時，這是一個策略問題。

為程式使用 GPL 是否會使其成為 GNU 軟體？

任何人都可以根據 GNU GPL 發布程式，但這並不使其成為 GNU 套件。

使程式成為 GNU 軟體套件意味著明確為 GNU 計劃做出貢獻。當程式的開發者和 GNU 計劃同意這樣做時，就會發生這種情況。如果您有興趣向 GNU 計劃貢獻程式，請寫信至<maintainers@gnu.org>。

如果我發現可能違反 GPL 的情況，我應該怎麼做？

您應該回報它。首先，盡可能地檢查事實。然後告訴特定 GPL 涵蓋程式的發布者或版權持有人。如果那是自由軟體基金會，請寫信至<license-violation@gnu.org>。否則，程式的維護者可能是版權持有人，或者可以告訴您如何聯絡版權持有人，因此請向維護者回報。

為什麼 GPL 允許使用者發布他們修改後的版本？

自由軟體的關鍵方面是用戶可以自由合作。絕對必要的是允許希望互相幫助的使用者與其他使用者分享他們的錯誤修復和改進。

有些人提出了 GPL 的替代方案，要求修改後的版本必須經過原始作者。只要原始作者跟上維護的需求，這在實踐中可能會很好地運作，但是如果作者停止（或多或少）做其他事情或不關注所有使用者的需求，這個方案就會崩潰。除了實際問題外，這個方案不允許使用者互相幫助。

有時，對修改後版本的控制被認為是防止使用者製作的各種版本之間混淆的一種手段。根據我們的經驗，這種混淆不是主要問題。GNU 計劃之外製作了許多 Emacs 版本，但使用者可以區分它們。GPL 要求版本的製作者將自己的名字放在上面，以區分它與其他版本，並保護其他維護者的聲譽。

GPL 是否要求將修改後版本的原始碼發布到公眾？

GPL 不要求您發布修改後的版本。您可以自由地進行修改並私下使用它們，而無需發布它們。這也適用於組織（包括公司）；一個組織可以製作修改後的版本並在組織內部使用它，而無需將其發布到組織外部。

但是，如果您以某種方式向公眾發布修改後的版本，GPL 要求您根據 GPL 向程式的使用者提供修改後的原始碼。

因此，GPL 允許以某些方式發布修改後的程式，而不是以其他方式發布；但是是否發布的決定取決於您。

我可以在同一台電腦上同時擁有一個 GPL 涵蓋的程式和一個無關的非自由程式嗎？

是的。“單純聚合”條款在 GPL 中明確了這一點，但這只是加強了我們認為無論如何都會成立的事情。

如果我知道某人擁有 GPL 涵蓋程式的副本，我可以要求他給我一份副本嗎？

不。GPL 允許他製作和重新發行程式的副本，如果且當他選擇這樣做時。當他不選擇重新發行程式時，他也有權不重新發行程式。

這個“對任何第三方有效的書面報價”是什麼意思？這是否意味著世界上任何人都可以獲得任何 GPL 授權程式的原始碼，無論如何？

如果您選擇透過書面報價提供原始碼，那麼任何向您索取原始碼的人都有權接收它。

如果您商業發行未附帶原始碼的二進位檔，GPL 規定您必須提供書面報價，以便稍後發行原始碼。當使用者非商業性地重新發行他們從您那裡收到的二進位檔時，他們必須傳遞此書面報價的副本。這意味著即使是沒有直接從您那裡獲得二進位檔的人，仍然可以收到原始碼的副本，以及書面報價。

我們要求報價對任何第三方有效的原因是，以便以這種方式間接接收二進位檔的人可以向您訂購原始碼。

GPL 規定，修改後的版本如果發布，必須“授權給…所有第三方”。這些第三方是誰？

第 2 節規定，您發行的修改版本必須根據 GPL 授權給所有第三方。“所有第三方” 意味著絕對的每個人—但這並不要求您為他們實際做任何事情。這僅表示他們擁有您版本在 GPL 下的許可證。

我是否需要在對 GPL 涵蓋程式的修改中聲明版權？

您無需在您的變更中聲明版權。然而，在大多數國家/地區，這會在預設情況下自動發生，因此如果您不想讓它們受到版權保護，則需要將您的變更明確置於公共領域。

無論您是否聲明您的變更的版權，無論哪種方式，您都必須根據 GPL 發布整個修改後的版本。（如果您發布修改後的版本）

如果一個程式結合了公共領域程式碼和 GPL 涵蓋的程式碼，我可以將公共領域部分取出並將其用作公共領域程式碼嗎？

如果您可以弄清楚哪個部分是公共領域部分並將其與其餘部分分開，則可以這樣做。如果程式碼是由其開發者放入公共領域的，那麼無論它在哪裡，它都屬於公共領域。

GPL 是否允許我出售程式的副本來賺錢？

是的，GPL 允許所有人這樣做。出售副本的權利是自由軟體定義的一部分。除了在一個特殊情況下，您可以收取的價格沒有限制。（一個例外是必須伴隨純二進位發行的書面報價，以提供原始碼。）

GPL 是否允許我對從我的發行網站下載程式收取費用？

是的。您可以對發行程式副本收取任何您想要的費用。如果您透過下載發行二進位檔，您必須提供“等效的訪問權限”來下載原始碼—因此，下載原始碼的費用可能不應高於下載二進位檔的費用。

GPL 是否允許我要求任何收到該軟體的人都必須支付我費用和/或通知我？

否。事實上，像這樣的要求會使程式變成非自由的。如果人們在獲得程式副本時必須付費，或者如果他們必須通知任何特定的人，那麼該程式就不是自由的。請參閱自由軟體的定義。

GPL 是一個自由軟體許可證，因此它允許人們使用甚至重新發行該軟體，而無需為此向任何人支付費用。

您可以向人們收取費用，以從您那裡獲得副本。您不能要求人們在從其他人獲得副本時向您付費。

如果我付費發行 GPL 授權軟體，我是否也必須免費向公眾提供？

否。但是，如果有人支付您的費用並獲得副本，GPL 會賦予他們自由，可以向公眾發布它，無論是否收費。例如，有人可以支付您的費用，然後將她的副本放在網站上供公眾使用。

GPL 是否允許我在保密協議下發行副本？

否。GPL 規定，從您那裡收到副本的任何人都擁有重新發行副本的權利，無論是否修改。您不得在任何更具限制性的基礎上發行作品。

如果有人要求您簽署 NDA 以接收 FSF 版權所有的 GPL 涵蓋軟體，請立即寫信至 license-violation@fsf.org 通知我們。

如果違規行為涉及具有其他版權持有人的 GPL 涵蓋程式碼，請通知該版權持有人，就像您對任何其他類型的 GPL 違規行為一樣。

GPL 是否允許我在保密協議下發行修改後的或測試版本？

否。GPL 規定，您修改後的版本必須帶有 GPL 中聲明的所有自由。因此，任何從您那裡收到您的版本副本的人都有權重新發行該版本的副本（無論是否修改）。您不得在更具限制性的基礎上發行作品的任何版本。

GPL 是否允許我在保密協議下開發修改後的版本？

是的。例如，您可以接受一份開發變更的合約，並同意在客戶說可以之前不發布您的變更。這是允許的，因為在這種情況下，沒有 GPL 涵蓋的程式碼在 NDA 下發行。

您也可以根據 GPL 向客戶發布您的變更，但同意除非客戶說可以，否則不將其發布給其他人。在這種情況下，也沒有 GPL 涵蓋的程式碼在 NDA 下或任何其他限制下發行。

GPL 將賦予客戶重新發行您的版本的權利。在這種情況下，客戶可能會選擇不使用該權利，但確實擁有該權利。

我希望我的工作獲得肯定。我希望人們知道我寫了什麼。如果我使用 GPL，我還能獲得肯定嗎？

您當然可以為這項工作獲得肯定。根據 GPL 發行程式的一部分是在您自己的名下（假設您是版權持有人）編寫版權聲明。GPL 要求所有副本都帶有適當的版權聲明。

為什麼 GPL 要求在程式的每個副本中都包含 GPL 的副本？

在作品中包含許可證副本至關重要，這樣每個獲得程式副本的人都可以知道他的權利是什麼。

可能很想包含一個指向許可證的 URL，而不是許可證本身。但是您無法確定該 URL 在五年或十年後是否仍然有效。二十年後，我們今天所知的 URL 可能不再存在。

確保擁有程式副本的人能夠繼續看到許可證的唯一方法，儘管網路中將會發生所有變更，是在程式中包含許可證的副本。

如果作品不比許可證本身長多少怎麼辦？

如果單個程式如此簡短，您不妨為其使用簡單的全權限許可證，而不是 GNU GPL。

我可以省略 GPL 的前言，或關於如何在您自己的程式上使用它的說明，以節省空間嗎？

前言和說明是 GNU GPL 的組成部分，不得省略。事實上，GPL 是受版權保護的，其許可證僅允許逐字複製整個 GPL。（您可以使用法律條款來製作另一個許可證，但它不會是 GNU GPL。）

前言和說明加起來約 5000 個字元，不到 GPL 總大小的 1/3。除非套件本身非常小，否則它們不會對軟體套件的大小造成實質性的分數變更。在這種情況下，您不妨使用簡單的全權限許可證，而不是 GNU GPL。

說兩個許可證“相容”是什麼意思？

為了將兩個程式（或它們的實質部分）組合成一個更大的作品，您需要獲得以這種方式使用這兩個程式的許可。如果這兩個程式的許可證允許這樣做，它們就是相容的。如果沒有辦法同時滿足這兩個許可證，它們就是不相容的。

對於某些許可證，組合的方式可能會影響它們是否相容—例如，它們可能允許將兩個模組連結在一起，但不允許將它們的程式碼合併到一個模組中。

僅僅在同一個系統中安裝兩個單獨的程式，它們的許可證沒有必要相容，因為這不會將它們組合成一個更大的作品。

說一個許可證“與 GPL 相容”是什麼意思？

這意味著另一個許可證和 GNU GPL 是相容的；您可以將在另一個許可證下發布的程式碼與在 GNU GPL 下發布的程式碼組合成一個更大的程式。

GPL 允許這樣的組合，前提是它是在 GNU GPL 下發布的。如果另一個許可證也允許這樣做，則它與 GPL 相容。

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

如果您這樣做，您的程式將無法在自由環境中完全使用。如果您的程式依賴於非自由函式庫來完成某項工作，那麼它就無法在自由世界中完成該工作。如果它依賴於非自由函式庫才能運行，那麼它就不能成為像 GNU 這樣的自由作業系統的一部分；它完全超出了自由世界的範圍。

因此，請考慮：您能否找到一種無需使用此函式庫即可完成工作的方法？您可以為該函式庫編寫一個自由的替代品嗎？

如果程式已經在使用非自由函式庫編寫，也許現在更改決定為時已晚。您不妨按原樣發布程式，而不是不發布它。但請在 README 中提及需要非自由函式庫是一個缺點，並建議更改程式的任務，使其在沒有非自由函式庫的情況下也能完成相同的工作。請建議任何考慮對程式進行實質性進一步工作的人，首先使其擺脫對非自由函式庫的依賴。

請注意，將某些非自由函式庫與 GPL 涵蓋的自由軟體結合使用也可能存在法律問題。請參閱關於帶有 GPL 不相容函式庫的 GPL 軟體的問題以獲取更多資訊。

如果我將 GPL 不相容的函式庫與 GPL 軟體一起使用，會出現什麼法律問題？

如果您連結的函式庫屬於 GPL 中的以下例外情況

然而，作為一個特殊的例外，發行的原始碼無需包含任何通常與執行檔運行的作業系統的主要組件（編譯器、核心等等）一起發行的內容（無論是原始碼形式還是二進位形式），除非該組件本身隨執行檔一起發行。

那麼您無需做任何特殊的事情即可使用它們；發行整個程式原始碼的要求不包括這些函式庫，即使您發行包含它們的連結執行檔也是如此。因此，如果您需要的函式庫來自專有作業系統的主要部分，GPL 規定人們可以將您的程式與它們連結，而沒有任何條件。

如果您希望您的程式連結到該例外情況未涵蓋的函式庫，您需要添加您自己的例外情況，完全在 GPL 之外。此版權聲明和許可證聲明允許與程式 FOO 連結

版權所有 (C) yyyy <版權持有人姓名>

本程式是自由軟體；您可以根據自由軟體基金會發布的 GNU 通用公共許可證條款重新發行和/或修改它；可以是第 2 版許可證，或（由您選擇）任何更新版本。

本程式的發行是希望它會很有用，但不提供任何擔保；甚至沒有對適銷性或特定用途適用性的暗示擔保。有關詳細資訊，請參閱 GNU 通用公共許可證。

您應該已收到與本程式一起發行的 GNU 通用公共許可證副本；如果沒有，請參閱 <https://gnu.dev.org.tw/licenses/>。

將 ABC 與其他模組靜態或動態連結正在製作基於 ABC 的組合作品。因此，GNU 通用公共許可證的條款和條件涵蓋了整個組合。

此外，作為一個特殊的例外，ABC 的版權持有人允許您將 ABC 程式與根據 GNU LGPL 發行的自由軟體程式或函式庫，以及 XYZ 許可證下 DEF 標準發行版中包含的程式碼（或此類程式碼的修改版本，許可證不變）組合。您可以複製和發行這樣一個系統，並遵循 GNU GPL 對於 ABC 和相關其他程式碼的許可證條款，前提是當 GNU GPL 要求發行原始碼時，您包含該其他程式碼的原始碼。

請注意，修改 ABC 程式的人員沒有義務為他們的修改版本授予此特殊例外；是否這樣做取決於他們的選擇。《GNU 通用公共許可證》允許在沒有此例外的情況下發布修改後的版本；此例外也使得發布帶有此例外的修改版本成為可能。

您應該將此文本放入適用例外的每個檔案中。

只有程式的著作權持有者才能合法授權此例外。如果您自己編寫了整個程式，那麼假設您的雇主或學校不聲明著作權，您就是著作權持有者——因此您可以授權此例外。但是，如果您想在您的程式碼中使用其他作者編寫的受 GPL 保護的程式碼部分，您不能為它們授權例外。您必須獲得這些程式的著作權持有者的批准。

當其他人修改程式時，他們不必為他們的程式碼做出相同的例外——是否這樣做取決於他們的選擇。

如果您打算連結的函式庫是非自由軟體，也請參閱關於編寫使用非自由軟體的自由軟體的章節。

為了在 GPL 下發布我的程式，我如何獲得我的程式的版權？

根據伯恩公約，任何書寫內容自固定形式起即自動享有著作權。因此，您不必做任何事情來「獲得」您所寫內容的著作權——只要沒有其他人可以聲稱擁有您的作品。

但是，在美國註冊著作權是一個非常好的主意。這將使您在美國處理侵權者時更有影響力。

如果其他人可能聲稱擁有著作權，情況就是您是員工或學生；那麼雇主或學校可能會聲稱您為他們做了這項工作，並且著作權屬於他們。他們是否擁有有效的主張將取決於諸如您居住地的法律，以及您的僱傭合約和您所做的工作類型等情況。如果有任何可能的疑慮，最好諮詢律師。

如果您認為雇主或學校可能提出索賠，您可以透過取得公司或學校經適當授權人員簽署的著作權免責聲明來明確解決問題。（您的直屬主管或教授通常沒有權限簽署此類免責聲明。）

如果我的學校可能想將我的程式變成他們自己的專有軟體產品怎麼辦？

現在許多大學試圖透過限制使用他們開發的知識和資訊來籌集資金，實際上他們的行為與商業企業沒有什麼不同。（關於這個問題及其影響的一般性討論，請參閱《The Kept University》，《大西洋月刊》，2000 年 3 月。）

如果您看到您的學校可能拒絕允許您的程式以自由軟體發布的任何機會，最好在盡可能早的階段提出這個問題。程式越接近實用，管理部門就越有可能想從您手中奪走它並在沒有您的情況下完成它。在早期階段，您有更大的影響力。

因此，我們建議您在程式只完成一半時接近他們，說：「如果您同意以自由軟體的形式發布這個程式，我將完成它。」不要認為這是在虛張聲勢。為了獲勝，您必須有勇氣說：「我的程式要么擁有自由，要么永遠不會誕生。」

您可以給我關於如何將 GPL 應用於我的程式的逐步說明嗎？

請參閱GPL 指令頁面。

我聽說有人在另一個許可證下獲得了 GPL 授權程式的副本。這有可能嗎？

GNU GPL 不允許使用者將其他許可證附加到程式上。但是，程式的著作權持有者可以平行地在多個不同的許可證下發布它。其中一個可能是 GNU GPL。

您副本中附帶的許可證，假設它是著作權持有者放入的，並且您合法獲得了該副本，那麼該許可證就是適用於您副本的許可證。

我想在 GNU GPL 下發布我編寫的程式，但我想在非自由程式中使用相同的程式碼。

發布非自由軟體在道德上總是有瑕疵的，但在法律上，您這樣做沒有障礙。如果您是程式碼的著作權持有者，您可以在不同的時間在各種不同的非獨佔許可證下發布它。

GPL 涵蓋程式的開發者是否受 GPL 約束？開發者的行為是否可能違反 GPL？

嚴格來說，GPL 是開發者授權他人使用、散布和更改程式的許可證。開發者本身不受其約束，因此無論開發者做什麼，這都不是「違反」GPL 的行為。

但是，如果開發者做了其他人做就會違反 GPL 的事情，開發者肯定會在社群中失去道德地位。

以 GPL 發行程式的開發者，之後可以授權給另一方獨家使用嗎？

不，因為公眾已經有權根據 GPL 使用該程式，並且該權利不能被撤銷。

我可以使用 GPL 涵蓋的編輯器（如 GNU Emacs）來開發非自由程式嗎？我可以使用 GPL 涵蓋的工具（如 GCC）來編譯它們嗎？

是的，因為編輯器和工具的著作權不涵蓋您編寫的程式碼。在法律上，使用它們不會對您用於程式碼的許可證施加任何限制。

由於技術原因，某些程式會將自身的部分內容複製到輸出中——例如，Bison 會將標準解析器程式複製到其輸出檔案中。在這種情況下，輸出中複製的文本受與原始程式碼中相同的許可證約束。同時，輸出的從程式輸入衍生的部分繼承輸入的著作權狀態。

碰巧的是，Bison 也可以用於開發非自由軟體。這是因為我們決定明確允許在 Bison 輸出檔案中使用 Bison 標準解析器程式，而不受限制。我們做出這個決定是因為還有其他與 Bison 相當的工具已經允許用於非自由軟體。

在使用 GPL 涵蓋程式的原始碼時，我是否擁有“合理使用”權？

是的，您可以。「合理使用」是在沒有任何特殊許可的情況下允許的使用。由於您不需要開發者的許可即可進行此類使用，因此無論開發者在許可證或其他地方說了什麼——無論該許可證是 GNU GPL 還是任何其他自由軟體許可證，您都可以這樣做。

但請注意，沒有世界通用的合理使用原則；哪些類型的使用被認為是「合理的」因國家/地區而異。

美國政府可以根據 GNU GPL 發布程式嗎？

如果程式是由美國聯邦政府僱員在其僱用期間編寫的，則該程式屬於公共領域，這意味著它不受著作權保護。由於 GNU GPL 是基於著作權的，因此此類程式不能根據 GNU GPL 發布。（但是，它仍然可以是自由軟體；公共領域程式是自由的。）

但是，當美國聯邦政府機構使用承包商開發軟體時，情況就不同了。合約可以要求承包商根據 GNU GPL 發布它。（GNU Ada 就是以這種方式開發的。）或者合約可以將著作權轉讓給政府機構，然後政府機構可以根據 GNU GPL 發布該軟體。

美國政府可以發布對 GPL 涵蓋程式的改進嗎？

是的。如果改進是由美國政府僱員在其僱用期間編寫的，則這些改進屬於公共領域。但是，改進後的版本作為一個整體，仍然受 GNU GPL 保護。這種情況下沒有問題。

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

有沒有辦法我可以 GPL 授權人們從使用我的程式中獲得的輸出？例如，如果我的程式用於開發硬體設計，我可以要求這些設計必須是自由的嗎？

一般來說，這在法律上是不可能的；著作權法不允許您對人們使用您的程式從其資料中製作的輸出提出任何異議。如果使用者使用您的程式輸入或轉換自己的資料，則輸出的著作權屬於他，而不是您。更一般地說，當程式將其輸入轉換為其他形式時，輸出的著作權狀態繼承自產生它的輸入。

因此，您對輸出的使用有異議的唯一方法是，如果輸出的很大一部分（或多或少）是從您程式中的文本複製而來的。例如，如果我們沒有在這個特定情況下做出例外，Bison 的部分輸出（見上文）將受 GNU GPL 保護。

即使沒有技術原因，您也可以人為地使程式將某些文本複製到其輸出中。但是，如果複製的文本沒有實際用途，使用者可以簡單地從輸出中刪除該文本，而只使用其餘部分。然後，他就不必遵守關於重新散布複製文本的條件。

在哪些情況下，GPL 程式的輸出也受 GPL 涵蓋？

僅當程式將自身的一部分複製到輸出中時。

如果我向 GPL 涵蓋的程式添加一個模組，我是否必須使用 GPL 作為我的模組的許可證？

GPL 規定，整個組合程式必須根據 GPL 發布。因此，您的模組必須可在 GPL 下使用。

但是您可以為您的程式碼的使用提供額外的許可。如果您願意，您可以根據比 GPL 更寬鬆但與 GPL 相容的許可證發布您的模組。許可證列表頁面提供了一部分與 GPL 相容的許可證列表。

如果一個函式庫是在 GPL（而非 LGPL）下發布的，這是否意味著任何使用它的程式都必須在 GPL 下？

是的，因為程式實際上連結到函式庫。因此，GPL 的條款適用於整個組合。與函式庫連結的軟體模組可能受各種與 GPL 相容的許可證約束，但整個作品必須根據 GPL 授權。另請參閱：許可證「與 GPL 相容」是什麼意思？

如果一個程式語言直譯器是在 GPL 下發布的，這是否意味著為其編寫的程式必須在 GPL 相容的許可證下？

當直譯器僅直譯一種語言時，答案是否定的。對於直譯器來說，被直譯的程式只是資料；基於著作權法的自由軟體許可證（如 GPL）不能限制您在直譯器上使用的資料。您可以以您喜歡的任何方式在任何資料（被直譯的程式）上運行它，並且沒有關於向任何人授權該資料的要求。

但是，當直譯器被擴展為提供與其他設施（通常是函式庫，但不一定是）的「綁定」時，被直譯的程式實際上會連結到它透過這些綁定使用的設施。因此，如果這些設施是在 GPL 下發布的，則使用它們的被直譯程式必須以與 GPL 相容的方式發布。JNI 或 Java Native Interface 就是這種綁定機制的一個範例；以這種方式存取的函式庫與呼叫它們的 Java 程式動態連結。這些函式庫也與直譯器連結。如果直譯器與這些函式庫靜態連結，或者如果它被設計為與這些特定函式庫動態連結，那麼它也需要以與 GPL 相容的方式發布。

另一個類似且非常常見的情況是為直譯器提供本身是被直譯的函式庫。例如，Perl 附帶許多 Perl 模組，而 Java 實作附帶許多 Java 類別。這些函式庫和呼叫它們的程式始終是動態連結在一起的。

一個結果是，如果您選擇在您的程式中使用 GPL 授權的 Perl 模組或 Java 類別，則無論組合的 Perl 或 Java 程式將在其上運行的 Perl 或 Java 直譯器中使用什麼許可證，您都必須以與 GPL 相容的方式發布該程式。

我正在使用 Microsoft Visual C++（或 Visual Basic）編寫一個 Windows 應用程式，我將根據 GPL 發布它。根據 GPL，是否允許將我的程式與 Visual C++（或 Visual Basic）執行時期函式庫動態連結？

GPL 允許這樣做，因為該執行時期函式庫通常隨附您正在使用的編譯器或直譯器。因此，它屬於 GPL 第 3 節中的例外情況。

這並不意味著編寫程式使其只能在 Windows 上運行是一個好主意。這樣做會導致程式成為自由軟體，但「受困」（在這種情況下，是被 Windows 而不是 Java 困住，但效果是相同的）。（歷史記錄：截至 2006 年 12 月，Sun 正處於根據 GNU GPL 重新發布其 Java 平台的中期。）

為什麼原始 BSD 許可證與 GPL 不相容？

因為它施加了一個 GPL 中沒有的特定要求；即，對程式廣告的要求。GPL 聲明

您不得對接受者行使本文授予的權利施加任何進一步的限制。

廣告條款提供了這樣一個進一步的限制，因此與 GPL 不相容。

修訂後的 BSD 許可證沒有廣告條款，這消除了問題。

程式及其外掛程式何時被視為單一組合程式？

這取決於主程式如何調用其外掛程式。如果主程式使用 fork 和 exec 來調用外掛程式，並且它們透過共享複雜的資料結構或來回傳輸複雜的資料結構來建立密切的通信，這會使它們成為一個單一的組合程式。一個主程式使用簡單的 fork 和 exec 來調用外掛程式，並且不在它們之間建立密切的通信，這會導致外掛程式成為一個單獨的程式。

如果主程式動態連結外掛程式，並且它們相互進行函式呼叫並共享資料結構，我們認為它們構成一個單一的組合程式，必須將其視為主程式和外掛程式的擴展。如果主程式動態連結外掛程式，但它們之間的通信僅限於使用某些選項調用外掛程式的「main」函式並等待其返回，則這是一個邊緣情況。

使用共享記憶體與複雜的資料結構通信幾乎等同於動態連結。

如果一個在 GPL 下發布的程式使用外掛程式，外掛程式的許可證有什麼要求？

請參閱此問題以確定何時將外掛程式和主程式視為單一的組合程式，以及何時將它們視為單獨的作品。

如果主程式和外掛程式是一個單一的組合程式，那麼這意味著您必須根據 GPL 或與 GPL 相容的自由軟體許可證授權外掛程式，並以符合 GPL 的方式散布它，並附帶原始程式碼。與其外掛程式分離的主程式對外掛程式沒有任何要求。

我可以在為非自由程式編寫外掛程式時應用 GPL 嗎？

請參閱此問題以確定何時將外掛程式和主程式視為單一的組合程式，以及何時將它們視為單獨的程式。

如果它們構成一個單一的組合程式，則這意味著 GPL 保護的外掛程式與非自由主程式的組合將違反 GPL。但是，您可以透過在您的外掛程式許可證中新增例外情況來解決該法律問題，從而允許將其與非自由主程式連結。

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

我可以發布一個旨在載入 GPL 涵蓋外掛程式的非自由程式嗎？

請參閱此問題以確定何時將外掛程式和主程式視為單一的組合程式，以及何時將它們視為單獨的程式。

如果它們構成一個單一的組合程式，則主程式必須根據 GPL 或與 GPL 相容的自由軟體許可證發布，並且當散布主程式以與這些外掛程式一起使用時，必須遵循 GPL 的條款。

但是，如果它們是獨立的作品，則外掛程式的許可證對主程式沒有任何要求。

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

你們有一個 GPL 授權程式，我想將其與我的程式碼連結以建立一個專有程式。我與你們的程式連結是否意味著我必須 GPL 授權我的程式？

是的。

如果是這樣，我是否有機會獲得你們程式在寬鬆 GPL 下的許可證？

您可以詢問，但大多數作者會堅定地說不。GPL 的想法是，如果您想將我們的程式碼包含在您的程式中，您的程式也必須是自由軟體。它旨在對您施加壓力，要求您以使其成為我們社群一部分的方式發布您的程式。

您始終有不使用我們程式碼的合法替代方案。

我如何允許僅在受控介面下將專有模組與我的 GPL 涵蓋函式庫連結？

將此文本新增到套件中每個檔案的許可證聲明中，在聲明該檔案根據 GNU GPL 散布的文本末尾

將 ABC 與其他模組靜態或動態連結正在製作基於 ABC 的組合作品。因此，GNU 通用公共許可證的條款和條件涵蓋了整個組合。

此外，作為一個特殊的例外，ABC 的著作權持有者允許您將 ABC 程式與根據 GNU LGPL 發布的自由軟體程式或函式庫以及僅透過 ABCDEF 介面與 ABC 通信的獨立模組組合。您可以複製和散布這樣一個系統，並遵循 GNU GPL 對於 ABC 和相關的其他程式碼的許可證條款，前提是當 GNU GPL 要求散布原始程式碼時和散布原始程式碼時，您包含該其他程式碼的原始程式碼。

請注意，修改 ABC 程式的人員沒有義務為他們的修改版本授予此特殊例外；是否這樣做取決於他們的選擇。《GNU 通用公共許可證》允許在沒有此例外的情況下發布修改後的版本；此例外也使得發布帶有此例外的修改版本成為可能。

只有程式的著作權持有者才能合法授權此例外。如果您自己編寫了整個程式，那麼假設您的雇主或學校不聲明著作權，您就是著作權持有者——因此您可以授權此例外。但是，如果您想在您的程式碼中使用其他作者編寫的受 GPL 保護的程式碼部分，您不能為它們授權例外。您必須獲得這些程式的著作權持有者的批准。

我編寫了一個與許多具有不同許可證的不同組件連結的應用程式。我對我的程式有哪些許可證要求感到非常困惑。您能告訴我可以使用的許可證有哪些嗎？

要回答這個問題，我們需要查看您的程式使用的每個組件的列表、該組件的許可證，以及簡要描述（每個組件幾句話就足夠了），描述您的函式庫如何使用該組件。兩個範例是

• 為了使我的軟體工作，它必須連結到 FOO 函式庫，該函式庫在 Lesser GPL 下可用。
• 我的軟體進行系統呼叫（使用我構建的命令列）來運行 BAR 程式，該程式在「GPL 下獲得許可，並有一個允許與 QUUX 連結的特殊例外」。

“單純聚合”和“將兩個模組合併為一個程式”之間有什麼區別？

僅僅聚合兩個程式意味著將它們並排放置在同一個 CD-ROM 或硬碟上。當它們是單獨的程式，而不是單個程式的組成部分時，我們使用這個術語。在這種情況下，如果其中一個程式受 GPL 保護，則它對另一個程式沒有影響。

組合兩個模組意味著將它們連接在一起，使它們形成一個更大的單個程式。如果任何一部分受 GPL 保護，則整個組合也必須根據 GPL 發布——如果您不能或不願意這樣做，您就不能組合它們。

什麼構成將兩個部分組合為一個程式？這是一個法律問題，最終將由法官決定。我們認為，一個適當的標準既取決於通信機制（exec、管道、rpc、共享位址空間內的函式呼叫等），也取決於通信的語義（交換哪些種類的資訊）。

如果模組包含在同一個可執行檔案中，它們肯定組合在一個程式中。如果模組被設計為在共享位址空間中連結在一起運行，這幾乎肯定意味著將它們組合到一個程式中。

相比之下，管道、Socket 和命令列參數通常是用於兩個單獨程式之間的通信機制。因此，當它們用於通信時，模組通常是單獨的程式。但是，如果通信的語義足夠密切，交換複雜的內部資料結構，這也可能成為將這兩個部分視為組合為一個更大的程式的基礎。

為什麼 FSF 要求 FSF 版權程式的貢獻者將版權轉讓給 FSF？如果我擁有 GPL 授權程式的版權，我也應該這樣做嗎？如果應該，該怎麼做？

我們的律師告訴我們，為了在法庭上針對違規者處於執行 GPL 的最佳位置，我們應該盡可能保持程式的著作權狀態簡單。我們透過要求每位貢獻者將其貢獻的著作權轉讓給 FSF，或放棄對其的著作權並將其置於公共領域來做到這一點。

我們還要求個別貢獻者從其雇主（如果有的話）那裡獲得著作權免責聲明，以便我們可以確保這些雇主不會聲稱擁有這些貢獻。

當然，如果所有貢獻者都將他們的程式碼置於公共領域，則沒有著作權可以執行 GPL。因此，我們鼓勵人們轉讓大型程式碼貢獻的著作權，而只將小的更改置於公共領域。

如果您想努力對您的程式執行 GPL，那麼您最好遵循類似的政策。如果您想了解更多資訊，請聯繫 <licensing@gnu.org>。

我可以修改 GPL 並製作修改後的許可證嗎？

您可以在另一個許可證中使用 GPL 條款（可能經過修改），前提是您以另一個名稱稱呼您的許可證，並且不包含 GPL 序言，並且前提是您充分修改末尾的使用說明，使其在措辭上明顯不同，並且不提及 GNU（儘管您描述的實際程序可能類似）。

如果您想在修改後的許可證中使用我們的序言，請寫信至 <licensing@gnu.org> 請求許可。為此，我們需要檢查實際的許可證要求，以查看我們是否批准它們。

儘管我們不會對您以這種方式製作修改後的許可證提出法律異議，但我們希望您三思而後行，不要這樣做。這種修改後的許可證幾乎可以肯定與 GNU GPL 不相容，這種不相容性阻礙了模組的有用組合。不同自由軟體許可證的簡單擴散本身就是一種負擔。

如果我使用根據 GNU GPL 獲得的軟體，我是否可以修改原始碼成為一個新的程式，然後將這個新程式商業發行和銷售？

您被允許在商業上出售修改後程式的副本，但只能根據 GNU GPL 的條款。因此，例如，您必須按照 GPL 中的描述向程式的使用者提供原始程式碼，並且必須允許他們按照 GPL 中的描述重新散布和修改它。

這些要求是包含您收到的 GPL 保護的程式碼到您自己的程式中的條件。

我可以將 GPL 用於軟體以外的其他事物嗎？

您可以將 GPL 應用於任何種類的作品，只要清楚什麼構成作品的「原始程式碼」即可。GPL 將其定義為用於對作品進行更改的首選形式。

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

LGPL 如何與 Java 協同工作？

請參閱本文以了解詳細資訊。 它的工作方式符合設計、意圖和預期。

考慮這種情況：1. X 在 GPL 下發布了專案 V1。2. Y 基於 V1 的變更和新程式碼為 V2 的開發做出貢獻。3. X 想要將 V2 轉換為非 GPL 許可證。X 是否需要 Y 的許可？

是的。Y 被要求根據 GNU GPL 發布其版本，這是基於 X 的版本 V1 的結果。沒有任何東西要求 Y 同意其程式碼的任何其他許可證。因此，X 必須先獲得 Y 的許可才能根據另一個許可證發布該程式碼。

我想將 GPL 涵蓋的軟體納入我的專有系統中。我可以這樣做嗎？

您不能將 GPL 保護的軟體合併到專有系統中。GPL 的目標是授予所有人複製、重新散布、理解和修改程式的自由。如果您可以將 GPL 保護的軟體合併到非自由系統中，它將具有使 GPL 保護的軟體也成為非自由軟體的效果。

包含 GPL 保護的程式的系統是該程式的擴展版本。GPL 規定，程式的任何擴展版本如果發布，都必須根據 GPL 發布。這有兩個原因：確保獲得軟體的使用者獲得他們應該享有的自由，並鼓勵人們回饋他們所做的改進。

但是，在許多情況下，您可以將 GPL 保護的軟體與您的專有系統一起散布。為了有效地做到這一點，您必須確保自由和非自由程式保持距離通信，它們沒有以使其有效地成為單個程式的方式組合在一起。

這與「合併」GPL 保護的軟體之間的區別部分是實質問題，部分是形式問題。實質部分是這樣的：如果兩個程式組合在一起，以至於它們實際上成為一個程式的兩個部分，那麼您就不能將它們視為兩個單獨的程式。因此，GPL 必須涵蓋整個內容。

如果這兩個程式保持良好分離，例如編譯器和核心，或者像編輯器和 Shell，那麼您可以將它們視為兩個單獨的程式——但您必須正確地做到這一點。問題僅僅是形式問題：您如何描述您正在做的事情。我們為什麼要關心這個？因為我們想確保使用者清楚地了解集合中 GPL 保護的軟體的自由狀態。

如果人們散布 GPL 保護的軟體，稱其為使用者知道部分是專有的系統的「一部分」，則使用者可能會對他們關於 GPL 保護的軟體的權利感到不確定。但是，如果他們知道他們收到的是一個自由程式和另一個程式，並排放置，他們的權利將是明確的。

在 GPL 下使用某個 GNU 程式不適合我們製作專有軟體的專案。你們會為我們破例嗎？這將意味著更多該程式的使用者。

抱歉，我們不允許這種例外情況。這是不對的。

最大化使用者數量不是我們的目標。相反，我們正在努力將關鍵自由賦予盡可能多的使用者。一般來說，專有軟體專案阻礙而不是幫助自由事業。

我們偶爾會做出許可證例外，以協助正在根據 GPL 以外的許可證製作自由軟體的專案。但是，我們必須看到充分的理由說明這將如何推進自由軟體事業。

當更改套件的散布條款似乎是服務於自由軟體事業的正確方法時，我們有時也會更改套件的散布條款；但我們對此非常謹慎，因此您必須向我們展示非常有說服力的理由。

我想將 GPL 涵蓋的軟體納入我的專有系統中。我可以透過在 GPL 涵蓋部分和專有部分之間放置一個“包裝器”模組，並在 GPL 相容的寬鬆許可證（例如 X11 許可證）下進行操作嗎？

不。X11 許可證與 GPL 相容，因此您可以將模組新增到 GPL 保護的程式中，並將其置於 X11 許可證下。但是，如果您要將它們都合併到一個更大的程式中，那麼整個程式將包括 GPL 保護的部分，因此它必須作為一個整體根據 GNU GPL 授權。

專有模組 A 僅透過 X11 授權的模組 B 與 GPL 保護的模組 C 通信這一事實在法律上是無關緊要的；重要的是模組 C 包含在整體中的事實。

libstdc++ 例外是否允許動態連結？

是的。例外的目的是允許人們使用 gcc 編譯專有軟體。

我想修改 GPL 保護的程式，並將它們與 Money Guzzler Inc. 的可移植性函式庫連結。我無法散布這些函式庫的原始程式碼，因此任何想要更改這些版本的使用者都必須單獨獲取這些函式庫。為什麼 GPL 不允許這樣做？

這有兩個原因。

首先，一個普遍的原因。如果我們允許 A 公司製作專有檔案，並允許 B 公司散布與該檔案連結的 GPL 保護的軟體，其效果將是在 GPL 中開一個大洞，大到足以開進一輛卡車。這將為隱瞞各種修改和擴展 GPL 保護的軟體的原始程式碼提供全權委託。

讓所有使用者都能存取原始程式碼是我們的主要目標之一，因此這種後果絕對是我們想要避免的。

更具體地說，與 Money Guzzler 函式庫連結的程式版本實際上並不是我們理解的自由軟體——它們不會附帶完整的原始程式碼，使使用者能夠更改和重新編譯程式。

如果模組 Q 的許可證有一個與 GPL 不相容的要求，但該要求僅在 Q 單獨發行時適用，而不是在 Q 包含在更大的程式中時適用，這是否使該許可證與 GPL 相容？我可以將 Q 與 GPL 涵蓋的程式結合或連結嗎？

如果程式 P 是在 GPL 下發布的，這意味著 它的任何和每個部分 都可以根據 GPL 使用。如果您整合模組 Q，並根據 GPL 發布組合程式 P+Q，則這意味著 P+Q 的任何部分都可以根據 GPL 使用。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 連結或組合。

我可以僅以二進位形式發行 GPL 涵蓋程式的修改版本嗎？

不。GPL 的重點在於所有修改後的版本都必須是自由軟體——這尤其意味著修改後版本的原始程式碼對使用者可用。

我只從網路上下載了二進位檔。如果我發行副本，我是否也必須取得原始碼並發行？

是的。一般規則是，如果您散布二進制檔案，您也必須散布完整的相應原始程式碼。對於您收到原始程式碼的書面要約的情況的例外情況非常有限。

我想透過實體媒體發行二進位檔，但不附帶原始碼。我可以透過 FTP 而不是郵寄方式提供原始碼嗎？

如果有人訂購原始程式碼，您應該透過郵購在實體媒體上提供原始程式碼。除了郵購選項外，我們歡迎您向人們提供透過 FTP 複製相應原始程式碼的方式，但透過 FTP 存取原始程式碼不足以滿足 GPL 第 3 節的要求。

當使用者訂購原始程式碼時，您必須確保將原始程式碼提供給該使用者。如果特定使用者可以方便地透過匿名 FTP 從您那裡獲得原始程式碼，那很好——這就完成了工作。但並非每個使用者都可以進行此類下載。其餘使用者同樣有權從您那裡獲得原始程式碼，這意味著您必須準備好透過郵寄方式將其寄給他們。

如果 FTP 存取足夠方便，也許沒有人會選擇郵購副本。如果是這樣，您將永遠不必寄送一份。但您不能假設這一點。

當然，最簡單的方法是首先將原始程式碼與二進制檔案一起寄送。

如果您透過 FTP 散布二進制檔案，您應該透過 FTP 散布原始程式碼。

我的朋友獲得了一個附帶提供原始程式碼要約的 GPL 保護的二進制檔案，並為我製作了一個副本。我自己可以使用該要約來獲取原始程式碼嗎？

是的，您可以。該要約必須向每個擁有其隨附二進制檔案副本的人開放。這就是為什麼 GPL 說您的朋友必須將要約的副本與二進制檔案的副本一起提供給您——以便您可以利用它。

我可以將二進位檔放在我的網際網路伺服器上，並將原始碼放在另一個網際網路網站上嗎？

GPL 說你必須提供存取原始碼的途徑，「從相同的地方」；也就是說，在二進制檔案旁邊。然而，如果你與另一個網站安排好存放必要的原始碼，並在二進制檔案旁邊放置一個連結或交叉引用到原始碼，我們認為這符合「從相同的地方」的條件。

然而請注意，僅僅找到今天碰巧擁有適當原始碼的某個網站，並告訴人們去那裡尋找是不夠的。明天該網站可能已經刪除了該原始碼，或者只是用同一個程式的較新版本取代了它。那麼你將不再符合 GPL 的要求。為了合理地盡力遵守，你需要與另一個網站達成明確的安排，從而確保只要你保持二進制檔案可用，原始碼就會在那裡可用。

我想以二進位形式發行 GPL 涵蓋程式的擴充版本。發行原始版本的原始碼是否足夠？

不，你必須提供對應於二進制檔案的原始碼。對應的原始碼指的是使用者可以從中重新建構相同二進制檔案的原始碼。

自由軟體的理念之一是，使用者應該能夠存取他們使用的程式的原始碼。使用你的版本的人應該能夠存取你的版本的原始碼。

GPL 的主要目標之一是透過確保對自由程式的改進本身也是自由的，來建立自由世界。如果你發布 GPL 涵蓋程式的改進版本，你必須在 GPL 下發布改進後的原始碼。

我想發行二進位檔，但發行完整的原始碼很不方便。如果我給使用者“標準”版本的差異檔以及二進位檔，這樣可以嗎？

這是一個善意的請求，但是這種提供原始碼的方法實際上並不能完成任務。

一年後想要原始碼的使用者可能無法在當時從另一個網站取得正確的版本。標準發布網站可能會有較新的版本，但相同的差異檔可能無法與該版本一起使用。

因此，你需要提供完整的原始碼，而不僅僅是差異檔，以及二進制檔案。

我想讓二進位檔可透過匿名 FTP 取得，但僅將原始碼發送給訂購的人。

如果你想透過匿名 FTP 發布二進制檔案，你仍然必須透過第 3 節列出的選項之一提供原始碼。這應該不難。如果你願意，你可以提供原始碼的書面報價；第 3(b) 節允許這樣做。但是，如果你能找到一個網站來發布你的程式，你肯定也能找到一個有空間存放原始碼的網站。

無論你如何發布原始碼，你提供的原始碼都必須與二進制檔案完全對應。特別是，你必須確保它們適用於相同版本的程式——而不是較舊的版本，也不是較新的版本。

你可以將原始碼和二進制檔案放在不同的機器上，前提是它們同樣容易取得，並且你在二進制檔案旁邊有資訊說明在哪裡可以找到原始碼。

我如何確保每個下載二進位檔的使用者也獲得原始碼？

你不必確保這一點。只要你提供原始碼和二進制檔案，讓使用者可以看到可用的東西並取得他們想要的東西，你就已經完成了對你的要求。是否下載原始碼取決於使用者。

我們對重新發布者的要求旨在確保使用者可以取得原始碼，而不是強迫使用者下載原始碼，即使他們不想要它。

一家公司正在網站上執行 GPL 授權程式的修改版本。GPL 是否規定他們必須發布其修改後的原始碼？

GPL 允許任何人製作修改後的版本並使用它，而無需將其發布給其他人。這家公司正在做的是這種情況的一個特例。因此，該公司不必發布修改後的原始碼。

人們必須有自由進行修改並私下使用它們，而無需發布這些修改，這是至關重要的。然而，將程式放在伺服器機器上供公眾存取，很難說是「私人」使用，因此在這種特殊情況下，要求發布原始碼是合理的。我們正在考慮在 GPL 第 3 版中做類似的事情，但我們還沒有具體的措辭。

在此期間，你可能想將 Affero GPL 用於設計用於網路伺服器的程式。

在一個組織或公司內部製作和使用多個副本是否算是「發布」？

不，在這種情況下，該組織只是為自己製作副本。因此，公司或其他組織可以開發修改後的版本，並透過自己的設施安裝該版本，而無需授權員工向外部人員發布該修改後的版本。

然而，當組織將副本轉移給其他組織或個人時，那就是發布。特別是，向承包商提供副本供異地使用就是發布。

如果有人偷走了一張包含 GPL 涵蓋程式版本的 CD，GPL 是否賦予他重新發行該版本的權利？

如果該版本已在其他地方發布，那麼竊賊可能確實有權根據 GPL 製作副本並重新發布它們，但如果他因偷竊 CD 而入獄，他可能必須等到獲釋後才能這樣做。

如果所討論的版本未發布，並且被公司視為商業機密，那麼發布它可能違反商業機密法，這取決於其他情況。GPL 不會改變這一點。如果公司試圖發布其版本，但仍然將其視為商業機密，那將違反 GPL，但如果公司尚未發布此版本，則不會發生此類違規行為。

如果一家公司將其他開發者的 GPL 涵蓋作品的副本作為商業機密發行給我怎麼辦？

該公司違反了 GPL，將不得不停止發布該程式。請注意這與上面的盜竊案例有何不同；當副本被盜時，公司並非有意發布副本，因此在這種情況下，公司並未違反 GPL。

如果一家公司將其自己的 GPL 涵蓋作品的副本作為商業機密發行給我怎麼辦？

如果發布的程式沒有包含任何其他人的 GPL 涵蓋的作品，那麼該公司沒有違反 GPL（有關更多資訊，請參閱「GPL 涵蓋程式的開發者是否受 GPL 約束？」）。但它正在就你可以對該程式做什麼做出兩個矛盾的陳述：你可以重新發布它，以及你不能。在接受副本之前，要求澄清該程式的使用條款是有意義的。

為什麼有些 GNU 函式庫是在普通的 GPL 而不是寬鬆 GPL 下發布的？

對於任何特定的函式庫使用 Lesser GPL 都構成對自由軟體的退讓。這意味著我們部分放棄了捍衛使用者自由的嘗試，以及分享基於 GPL 涵蓋軟體之上的內容的一些要求。就其本身而言，這些都是變得更糟的改變。

有時，局部的退讓是一種好的策略。有時，對函式庫使用 LGPL 可能會導致更廣泛地使用該函式庫，從而為其帶來更多改進、對自由軟體的更廣泛支持等等。如果這種情況在很大程度上發生，這可能對自由軟體有利。但是這種情況會發生多少呢？我們只能推測。

最好在每個函式庫上試用 LGPL 一段時間，看看它是否有幫助，如果 LGPL 沒有幫助，則改回 GPL。但這是不可行的。一旦我們對某個特定函式庫使用 LGPL，改回將會很困難。

因此，我們根據具體情況決定每個函式庫使用哪個許可證。關於我們如何判斷這個問題，有 一個長篇解釋。

為什麼程式應該說“GPL 第 2 版或任何更新版本”？

我們不時地，每隔幾年，我們會更改 GPL——有時是為了澄清它，有時是為了允許以前不允許的某些類型的使用，有時是為了收緊要求。（上次更改是在 1991 年。）在每個程式中使用這個「間接指標」使我們有可能在更新 GPL 時更改整個 GNU 軟體集合的發布條款。

如果每個程式都缺少間接指標，我們將被迫與眾多版權持有人詳細討論變更，這幾乎是不可能的。實際上，GNU 軟體擁有統一發布條款的機會將為零。

假設一個程式說「GPL 第 2 版或任何後續版本」，並且發布了 GPL 的新版本。如果新的 GPL 版本給予額外的許可，則該許可將立即提供給該程式的所有使用者。但是，如果新的 GPL 版本有更嚴格的要求，它將不會限制目前版本程式的使用，因為它仍然可以在 GPL 第 2 版下使用。當一個程式說「GPL 第 2 版或任何後續版本」時，使用者將始終被允許根據 GPL 第 2 版的條款使用它，甚至更改它——即使在 GPL 的後續版本可用之後也是如此。

如果新的 GPL 版本中更嚴格的要求對於現有軟體不必遵守，那麼它有什麼用呢？一旦 GPL 第 3 版可用，大多數 GPL 涵蓋程式的開發人員將發布其程式的後續版本，指定「GPL 第 3 版或任何後續版本」。然後，使用者將不得不在程式的後續版本中遵循 GPL 第 3 版中更嚴格的要求。

但是，開發人員沒有義務這樣做；如果開發人員願意，他們可以繼續允許使用 GPL 的先前版本。

為什麼你們不對手冊使用 GPL？

可以將 GPL 用於手冊，但 GNU 自由文件許可證 (GFDL) 更適合手冊。

GPL 是為程式設計的；它包含許多對於程式至關重要的複雜條款，但對於書籍或手冊來說，這些條款將會很繁瑣且不必要。例如，任何在紙上出版該書的人都必須在每本印刷副本中包含機器可讀的該書「原始碼」，或者提供書面報價稍後寄送「原始碼」。

同時，GFDL 具有幫助自由手冊出版商從銷售副本中獲利的條款——例如封面文字。背書章節的特殊規則使得將 GFDL 用於官方標準成為可能。這將允許修改後的版本，但它們不能被標記為「標準」。

使用 GFDL，我們允許更改涵蓋其技術主題的手冊文本。能夠更改技術部分非常重要，因為更改程式的人應該更改文件以對應。這樣做的自由是道德上的必然。

我們的手冊還包括說明我們關於自由軟體的政治立場的章節。我們將這些標記為「不可變的」，以便它們不能被更改或刪除。GFDL 為這些「不可變章節」做出了規定。

GPL 如何適用於字型？

字型授權是一個複雜的問題，需要認真考慮。以下許可證例外是實驗性的，但已批准用於一般用途。我們歡迎對此主題提出建議——請參閱這篇 解釋性文章 並寫信至 <licensing@gnu.org>。

若要使用此例外，請將此文字新增至套件中每個檔案的許可證聲明（在可能的範圍內），在說明該檔案根據 GNU GPL 發布的文字末尾。

作為一個特殊例外，如果你建立一個使用此字型的文件，並將此字型或此字型的未修改部分嵌入到文件中，則此字型本身不會導致產生的文件受 GNU 通用公共許可證的約束。但是，此例外不使文件可能受 GNU 通用公共許可證約束的任何其他原因失效。如果你修改此字型，你可以將此例外擴展到你的字型版本，但你沒有義務這樣做。如果你不希望這樣做，請從你的版本中刪除此例外聲明。

我正在編寫一個網站維護系統（有些人稱之為「內容管理系統」），或一些其他從範本產生網頁的應用程式。我應該對這些範本使用什麼許可證？

範本非常次要，不值得使用著作權保護它們。對次要作品使用著作權通常是無害的，但範本是一種特殊情況，因為它們與應用程式使用者提供的資料結合在一起，並且組合被發布。因此，我們建議你根據簡單的寬鬆條款授權你的範本。

某些範本會呼叫 Javascript 函式。由於 Javascript 通常不是微不足道的，因此值得使用著作權保護。由於範本將與使用者資料結合使用，因此範本 + 使用者資料 + Javascript 可能被認為是著作權法下的一部作品。需要在 Javascript（受著作權保護）和使用者程式碼（通常在不相容的條款下）之間劃清界線。

這是針對執行此操作的 Javascript 程式碼的例外情況。

作為 GPL 的一個特殊例外，任何僅呼叫此程式碼的函式，並為此目的透過引用包含它的 HTML 檔案，都應被視為著作權法目的的獨立作品。此外，此程式碼的版權持有人授予你將此程式碼與根據 GNU LGPL 發布的自由軟體函式庫結合使用的許可。你可以根據 GNU GPL（針對此程式碼）和 LGPL（針對函式庫）的條款複製和發布此類系統。如果你修改此程式碼，你可以將此例外擴展到你的程式碼版本，但你沒有義務這樣做。如果你不希望這樣做，請從你的版本中刪除此例外聲明。

我可以發布一個我使用非自由工具開發的 GPL 授權程式嗎？

你用來編輯原始碼、編譯它、研究它或記錄它的程式通常對於與該原始碼授權相關的問題沒有任何影響。

但是，如果你將非自由函式庫與原始碼連結，那將是你需要處理的問題。這並不妨礙根據 GPL 發布原始碼，但如果這些函式庫不符合「系統函式庫」例外，你應該附加明確的聲明，允許將你的程式與它們連結。FSF 可以為你提供有關如何執行此操作的建議。

是否有 GPL 的其他語言翻譯版本？

擁有 GPL 的非英語翻譯將會很有用。人們甚至編寫了翻譯並將其發送給我們。但我們不敢批准它們作為正式有效的翻譯。這帶來了如此巨大的風險，我們不敢接受它。

法律文件在某些方面就像程式。翻譯它就像將程式從一種語言和作業系統翻譯到另一種語言和作業系統。只有精通兩種語言的律師才能做到——即使這樣，也存在引入錯誤的風險。

如果我們要正式批准 GPL 的翻譯，我們將允許任何人做翻譯所說他們可以做的任何事情。如果它是完全準確的翻譯，那很好。但是，如果翻譯中存在錯誤，結果可能是我們無法彌補的災難。

如果一個程式有錯誤，我們可以發布一個新版本，最終舊版本將或多或少地消失。但是，一旦我們允許所有人根據特定的翻譯行事，如果我們稍後發現它有錯誤，我們就無法收回該許可。

熱心的人有時會主動為我們做翻譯工作。如果問題是要找到人來做這項工作，這將解決問題。但實際問題是錯誤的風險，而主動做這項工作並不能避免風險。我們不可能授權非律師撰寫的翻譯。

因此，目前，我們不批准 GPL 的翻譯作為全球有效且具有約束力的翻譯。相反，我們正在做兩件事。

• 將人們轉介到非官方翻譯。這意味著我們允許人們編寫 GPL 的翻譯，但我們不批准它們作為法律上有效且具有約束力的翻譯。

  未經批准的翻譯沒有法律效力，並且應明確說明這一點。它應該標記如下。

  此 GPL 翻譯是非正式的，未經自由軟體基金會正式批准為有效。為了完全確定允許做什麼，請參考原始 GPL（英文）。

  但是，未經批准的翻譯可以作為理解英文 GPL 的提示。對於許多使用者來說，這就足夠了。

  但是，在商業活動中使用 GNU 軟體的企業，以及進行公共 ftp 發布的人員，應該需要檢查真正的英文 GPL，以確保它允許什麼。

• 發布僅在單一國家/地區有效的翻譯。

  我們正在考慮發布僅在一個國家/地區正式有效的翻譯的想法。這樣，如果出現錯誤，它將僅限於該國家/地區，並且損害不會太大。

  仍然需要一位同情且有能力的律師付出相當多的專業知識和努力才能進行翻譯，因此我們無法承諾很快會有任何此類翻譯。

如果一個程式語言直譯器的許可證與 GPL 不相容，我可以在其上執行 GPL 涵蓋的程式嗎？

當解釋器只是解釋一種語言時，答案是肯定的。對於解釋器來說，被解釋的程式只是資料；GPL 不限制你使用什麼工具來處理程式。

但是，當解釋器被擴展以提供與其他設施（通常是，但不一定是函式庫）的「綁定」時，被解釋的程式實際上連結到它透過這些綁定使用的設施。JNI 或 Java Native Interface 就是這樣一種設施的範例；以這種方式存取的函式庫會與呼叫它們的 Java 程式動態連結。

因此，如果這些設施是在與 GPL 不相容的許可證下發布的，則情況就像以任何其他方式與與 GPL 不相容的函式庫連結一樣。這意味著。

1. 如果你正在編寫程式碼並根據 GPL 發布它，你可以聲明一個明確的例外，允許將其與這些與 GPL 不相容的設施連結。
2. 如果你根據 GPL 編寫和發布了該程式，並且你專門將其設計為與這些設施一起工作，人們可以將其視為允許他們將其與這些設施連結的隱含例外。但如果這就是你的意圖，最好明確說明。
3. 你不能採用別人的 GPL 涵蓋的程式碼並以這種方式使用它，或向其新增此類例外。只有該程式碼的版權持有人才能新增例外。

誰有權執行 GPL？

由於 GPL 是版權許可證，因此可以由軟體的版權持有人執行。如果你發現違反 GPL 的行為，你應該通知所涉及的 GPL 涵蓋軟體的開發人員。他們要么是版權持有人，要么與版權持有人有關聯。

此外，我們鼓勵使用者使用任何可用的法律機制來取得完整且對應的原始碼（這是他們的權利），並強制完全遵守 GNU GPL。畢竟，我們開發 GNU GPL 是為了讓軟體對所有使用者免費。

在物件導向語言（如 Java）中，如果我使用一個 GPL 授權的類別而不進行修改，並對其進行子類別化，那麼 GPL 在哪些方面影響了更大的程式？

建立子類別是建立衍生作品。因此，當你建立 GPL 授權類別的子類別時，GPL 的條款會影響整個程式。

如果我將我的程式移植到 GNU/Linux，這是否意味著我必須根據 GPL 或其他自由軟體許可證將其作為自由軟體發布？

一般來說，答案是否定的——這不是法律要求。具體來說，答案取決於你想使用的函式庫以及它們的許可證是什麼。大多數系統函式庫要么使用 GNU Lesser GPL，要么使用 GNU GPL 加上允許將函式庫與任何內容連結的例外。這些函式庫可以在非自由程式中使用；但在 Lesser GPL 的情況下，它確實有一些你必須遵守的要求。

某些函式庫僅根據 GNU GPL 發布；你必須使用與 GPL 相容的許可證才能使用這些函式庫。但這些通常是更專業的函式庫，你在另一個平台上不會有任何非常類似的函式庫，因此你可能不會發現自己想要使用這些函式庫進行簡單的移植。

當然，如果你的軟體不是自由的，那麼它就不是對我們社群的貢獻，並且重視自由的人會拒絕使用它。只有願意放棄自由的人才會使用你的軟體，這意味著它實際上會起到誘使人們失去自由的作用。

如果你希望有一天回顧你的職業生涯，並感覺它為一個美好而自由的社會的成長做出了貢獻，你需要讓你的軟體成為自由軟體。

我剛發現一家公司擁有 GPL 授權程式的副本，並且需要花錢才能獲得它。他們不將其放在網際網路上是否違反了 GPL？

不。GPL 不要求任何人使用網際網路進行發布。它也不要求任何特定的人重新發布該程式。而且（在一個特殊情況之外），即使有人有時決定重新發布該程式，GPL 也沒有說他必須向你個人或任何其他特定的人發布副本。

GPL 要求的是，如果他願意，他必須有自由向你發布程式副本。一旦版權持有人確實向某人發布了程式副本，該人就可以隨後根據自己的意願將程式重新發布給你或任何其他人。

我可以發布一個帶有許可證的程式，該許可證規定您可以根據 GPL 發行其修改後的版本，但您不能根據 GPL 發行原始版本本身嗎？

不。這樣的許可證會是自相矛盾的。讓我們看看它對我作為使用者的影響。

假設我從原始版本（稱之為版本 A）開始，新增一些程式碼（讓我們想像它是 1000 行），並根據 GPL 發布該修改後的版本（稱之為版本 B）。GPL 說任何人都可以再次更改版本 B，並根據 GPL 發布結果。因此，我（或其他人）可以刪除這 1000 行，產生版本 C，它具有與版本 A 相同的程式碼，但受 GPL 約束。

如果你試圖阻止該途徑，方法是在許可證中明確聲明我不允許透過從版本 B 中刪除這些行來根據 GPL 複製與版本 A 完全相同的內容，實際上許可證現在說我不能以 GPL 允許的所有方式完全使用版本 B。換句話說，許可證實際上不允許使用者根據 GPL 發布諸如 B 之類的修改版本。

將副本移動到多數持有且受控制的子公司是否構成發行？

將副本移入或移出此子公司是否構成「發布」應根據適當司法管轄區的著作權法在每個案例中決定。GPL 不會也不能凌駕於當地法律之上。美國著作權法在這方面並不明確，但似乎不認為這是發布。

如果在某些國家/地區，這被視為發布，並且子公司必須獲得重新發布該程式的權利，那也不會產生實際差異。子公司由母公司控制；無論是否有權利，除非母公司決定這樣做，否則它不會重新發布該程式。

軟體安裝程式可以要求人們點擊以同意 GPL 嗎？如果我根據 GPL 獲得一些軟體，我是否必須同意任何事情？

某些軟體封裝系統有一個位置，要求你點擊或以其他方式表明同意 GPL 的條款。這既不是必需的，也不是禁止的。無論是否點擊同意，GPL 的規則都保持不變。

僅僅同意 GPL 並不會對你施加任何義務。你無需同意任何事情即可僅僅使用根據 GPL 授權的軟體。只有在你修改或發布軟體時，你才有義務。如果點擊同意 GPL 真的讓你感到困擾，沒有什麼可以阻止你駭入 GPL 授權的軟體來繞過這一點。

我想將 GPL 授權軟體與某種安裝軟體捆綁在一起。該安裝程式是否需要具有 GPL 相容的許可證？

不。安裝程式及其安裝的檔案是獨立的作品。因此，GPL 的條款不適用於安裝軟體。