GNU 授權條款常見問題

“GPL” 代表什麼？ (#WhatDoesGPLStandFor)

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

自由軟體是否意味著使用 GPL？ (#DoesFreeSoftwareMeanUsingTheGPL)

完全不是——還有許多其他自由軟體授權條款。我們有一個不完整的清單。任何為使用者提供某些特定自由的授權條款都是自由軟體授權條款。

為什麼我應該使用 GNU GPL 而不是其他自由軟體授權條款？ (#WhyUseGPL)

使用 GNU GPL 將要求所有發布的改進版本都是自由軟體。這表示您可以避免必須與您自己作品的專有修改版本競爭的風險。但是，在某些特殊情況下，最好使用更寬鬆的授權條款。

所有 GNU 軟體都使用 GNU GPL 作為其授權條款嗎？ (#DoesAllGNUSoftwareUseTheGNUGPLAsItsLicense)

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

為程式使用 GPL 會使其成為 GNU 軟體嗎？ (#DoesUsingTheGPLForAProgramMakeItGNUSoftware)

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

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

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

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

為什麼 GPL 允許使用者發布其修改後的版本？ (#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions)

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

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

有時，建議控制修改後的版本是為了防止使用者製作的各種版本之間產生混淆。根據我們的經驗，這種混淆不是主要問題。在 GNU 專案之外製作了許多版本的 Emacs，但使用者可以區分它們。GPL 要求版本的製作者在其上註明姓名，以區分它與其他版本，並保護其他維護者的聲譽。

GPL 是否要求將修改版本的原始碼公開發布？ (#GPLRequireSourcePostedPublic)

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

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

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

我可以在同一台電腦上同時擁有 GPL 涵蓋的程式和不相關的非自由程式嗎？ (#GPLAndNonfreeOnSameMachine)

可以。

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

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

GPLv2 中的「對任何第三方有效的書面報價」是什麼意思？這是否表示世界上所有人都可以取得任何 GPL 程式的原始碼，無論如何？ (#WhatDoesWrittenOfferValid)

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

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

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

GPLv2 規定修改後的版本（如果發布）必須「授權給…所有第三方」。這些第三方是誰？ (#TheGPLSaysModifiedVersions)

第 2 節規定您發行的修改後的版本必須根據 GPL 授權給所有第三方。「所有第三方」表示絕對每個人——但這並不要求您為他們做任何實際的事情。這僅表示他們擁有您根據 GPL 對您的版本提供的授權。

我是否需要對我對 GPL 涵蓋程式的修改主張版權？ (#RequiredToClaimCopyright)

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

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

GPL 對於將某些程式碼翻譯成不同的程式語言有什麼規定？ (#TranslateCode)

根據版權法，作品的翻譯被視為一種修改。因此，GPL 對於修改版本的規定也適用於翻譯版本。翻譯受原始程式版權保護。

如果原始程式帶有自由授權條款，則該授權條款允許翻譯它。您如何使用和授權翻譯後的程式取決於該授權條款。如果原始程式根據某些版本的 GNU GPL 授權，則翻譯後的程式必須受相同版本的 GNU GPL 保護。

如果程式將公共領域程式碼與 GPL 涵蓋程式碼結合在一起，我可以取出公共領域部分並將其用作公共領域程式碼嗎？ (#CombinePublicDomainWithGPL)

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

GPL 是否允許我出售程式的副本來獲利？ (#DoesTheGPLAllowMoney)

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

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

是的。您可以對散布程式副本收取任何您希望的費用。在 GPLv2 下，如果您透過下載方式散布二進位檔案，您必須提供「同等存取權」以下載原始碼——因此，下載原始碼的費用不得高於下載二進位檔案的費用。如果散布的二進位檔案是以 GPLv3 授權，那麼您必須以相同方式，在相同地點提供同等存取權以取得原始碼，且不得額外收費。

GPL 是否允許我要求任何收到軟體的人都必須付費給我及/或通知我？ (#DoesTheGPLAllowRequireFee)

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

GPL 是一個自由軟體授權條款，因此它允許人們使用，甚至重新散布軟體，而無需為此支付任何人費用。

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

如果我付費散布 GPL 授權的軟體，我是否也必須免費公開提供？ (#DoesTheGPLRequireAvailabilityToPublic)

不。然而，如果有人支付您的費用並取得副本，GPL 賦予他們自由公開發布該副本的權利，無論是否收費。例如，有人可以支付您的費用，然後將她的副本放在網站上供大眾使用。

GPL 是否允許我根據保密協議散布副本？ (#DoesTheGPLAllowNDA)

不行。GPL 聲明，任何從您那裡收到副本的人都有權重新散布副本，無論是否修改過。您不得在任何更具限制性的基礎上散布該作品。

如果有人要求您簽署保密協議以接收 FSF 擁有著作權的 GPL 涵蓋軟體，請立即寫信至 license-violation@fsf.org 通知我們。

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

GPL 是否允許我根據保密協議散布修改版或 beta 版本？ (#DoesTheGPLAllowModNDA)

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

GPL 是否允許我根據保密協議開發修改版？ (#DevelopChangesUnderNDA)

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

您也可以在 GPL 下向客戶發布您的變更，但同意除非客戶說可以，否則不向任何人發布。在這種情況下，也沒有 GPL 涵蓋的程式碼在保密協議下，或在任何額外限制下散布。

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

我希望我的工作獲得肯定。我希望人們知道我寫了什麼。如果我使用 GPL，我仍然可以獲得肯定嗎？ (#IWantCredit)

您當然可以因您的工作獲得肯定。在 GPL 下發布程式的一部分，是以您自己的名義撰寫著作權聲明（假設您是著作權持有人）。GPL 要求所有副本都帶有適當的著作權聲明。

GPL 是否允許我添加條款，要求在使用 GPL 涵蓋的軟體或其輸出的研究論文中引用或致謝？ (#RequireCitation)

不行，GPL 條款不允許這樣做。雖然我們認可適當的引用是學術出版物的重要組成部分，但引用不能作為 GPL 的額外要求添加。要求在使用了 GPL 授權軟體的研究論文中引用，超出了 GPLv3 第 7(b) 節中可接受的額外要求範圍，因此將被視為 GPL 第 7 節下的額外限制。而且著作權法不允許您對軟體的輸出施加此類要求，無論它是否根據 GPL 或其他授權條款授權。

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

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

包含指向授權條款的 URL 而不是授權條款本身可能很誘人。但您無法確定該 URL 在五年或十年後是否仍然有效。二十年後，我們今天所知的 URL 可能已不復存在。

確保擁有程式副本的人將能夠繼續看到授權條款的唯一方法，儘管網路中會發生所有變化，就是在程式中包含授權條款的副本。

僅僅將 GNU GPL 的副本放在我的儲存庫中就足夠了嗎？ (#LicenseCopyOnly)

僅僅將 GNU GPL 的副本放在儲存庫中的檔案中，並未明確聲明同一個儲存庫中的程式碼可以在 GNU GPL 下使用。如果沒有這樣的聲明，就不完全清楚授權條款中的許可是否真的適用於任何特定的原始碼檔案。明確聲明這一點可以消除所有疑慮。

一個僅包含授權條款的檔案，而沒有聲明某些其他檔案受該授權條款約束，就像一個僅包含一個從未在其他任何地方調用過的子程式的檔案。這種相似性並不完美：律師和法院可能會運用常識，並得出結論，您一定是因為想要以這種方式授權程式碼，才將 GNU GPL 的副本放在那裡。或者他們可能不會。為什麼要留下不確定性呢？

此聲明應位於每個原始碼檔案中。程式的 README 檔案中的明確聲明在法律上是充分的只要它隨附程式碼，但它們很容易被分開。為什麼要冒著程式碼授權條款不確定性的風險呢？

這與 GNU GPL 的具體細節無關。這對於任何自由授權條款都是如此。

為什麼我應該在每個原始碼檔案中放置授權條款聲明？ (#NoticeInSourceFile)

您應該在每個原始碼檔案的開頭放置一個聲明，說明它受什麼授權條款約束，以避免程式碼與其授權條款斷開連結的風險。如果您的儲存庫的 README 檔案聲明原始碼檔案受 GNU GPL 約束，如果有人將該檔案複製到另一個程式中會發生什麼？另一個上下文可能不會顯示該檔案的授權條款是什麼。它可能看起來具有其他授權條款，或者根本沒有授權條款（這會使程式碼變成非自由軟體）。

在每個原始碼檔案的開頭添加著作權聲明和授權條款聲明很容易，並且可以避免這種混淆。

這與 GNU GPL 的具體細節無關。這對於任何自由授權條款都是如此。

如果作品不是很長怎麼辦？ (#WhatIfWorkIsShort)

如果整個軟體套件包含的程式碼很少——我們使用的基準是少於 300 行——您最好對其使用寬鬆的許可式授權條款，而不是像 GNU GPL 這樣的著作權保護授權條款。（除非，也就是說，程式碼特別重要。）對於這種情況，我們建議使用 Apache 授權條款 2.0。

我可以省略 GPL 的序言，或關於如何在您自己的程式中使用它的說明，以節省空間嗎？ (#GPLOmitPreamble)

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

序言和說明加起來約 1000 個字，不到 GPL 總大小的 1/5。除非軟體套件本身非常小，否則它們不會使軟體套件的大小發生顯著的分數變化。在這種情況下，您最好使用簡單的全許可式授權條款，而不是 GNU GPL。

說兩個授權條款「相容」是什麼意思？ (#WhatIsCompatible)

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

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

如果您只是想在同一個系統中安裝兩個單獨的程式，則不需要它們的授權條款相容，因為這不會將它們組合成一個更大的作品。

說一個授權條款「與 GPL 相容」是什麼意思？ (#WhatDoesCompatMean)

這表示另一個授權條款和 GNU GPL 是相容的；您可以將在另一個授權條款下發布的程式碼，與在 GNU GPL 下發布的程式碼組合成一個更大的程式。

所有 GNU GPL 版本都允許私下進行此類組合；它們也允許散布此類組合，前提是該組合以相同的 GNU GPL 版本發布。如果另一個授權條款也允許這樣做，那麼它就與 GPL 相容。

GPLv3 比 GPLv2 與更多授權條款相容：它允許您與具有特定類型額外要求的程式碼進行組合，這些額外要求在 GPLv3 本身中沒有。第 7 節有更多關於此資訊，包括允許的額外要求列表。

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

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

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

如果程式已經使用非自由軟體函式庫編寫，那麼可能已經太晚而無法改變決定。您不妨按原樣發布該程式，而不是不發布它。但請在 README 檔案中註明，需要非自由軟體函式庫是一個缺點，並建議更改程式的任務，以便在沒有非自由軟體函式庫的情況下完成相同的工作。請建議任何考慮對該程式進行實質性進一步工作的人，首先使其擺脫對非自由軟體函式庫的依賴。

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

我可以將 GPL 程式與專有系統函式庫連結嗎？ (#SystemLibraryException)

GPL 的兩個版本都對其著作權保護條款有一個例外，通常稱為系統函式庫例外。如果您想要使用的 GPL 不相容函式庫符合系統函式庫的標準，那麼您無需執行任何特殊操作即可使用它們；完整程式的原始碼散布要求不包括這些函式庫，即使您散布包含它們的連結可執行檔。

關於什麼算是「系統函式庫」的標準，在不同版本的 GPL 之間有所不同。GPLv3 在第 1 節中明確定義了「系統函式庫」，以將其排除在「相應原始碼」的定義之外。GPLv2 在第 3 節末尾以稍微不同的方式處理了這個問題。

在哪些方面我可以連結或組合 AGPLv3 涵蓋的程式碼和 GPLv3 涵蓋的程式碼？ (#AGPLGPL)

這些授權條款中的每一個都明確允許與另一個授權條款下的程式碼連結。您始終可以將 GPLv3 涵蓋的模組與 AGPLv3 涵蓋的模組連結，反之亦然。無論某些模組是否為函式庫，情況都是如此。

如果我將 GPL 不相容的函式庫與 GPL 軟體一起使用，會出現哪些法律問題？ (#GPLIncompatibleLibs)

如果您希望您的程式連結到不屬於系統函式庫例外的函式庫，您需要提供許可才能這樣做。以下是您可以使用的兩個範例授權條款聲明，一個用於 GPLv3，另一個用於 GPLv2。在這兩種情況下，您都應該將此文字放在您授予此許可的每個檔案中。

只有程式的著作權持有人才能合法地根據這些條款發布他們的軟體。如果您自己編寫了整個程式，那麼假設您的雇主或學校沒有聲稱擁有著作權，您就是著作權持有人——因此您可以授權例外。但是，如果您想在您的程式碼中使用其他作者的其他 GPL 涵蓋程式的部分，您不能為它們授權例外。您必須獲得這些程式的著作權持有人的批准。

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

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

如果您使用的是 GPLv3，您可以透過根據第 7 節授予額外許可來實現此目標。以下授權條款聲明將做到這一點。您必須將方括號中的所有文字替換為適合您程式的文字。如果不是每個人都可以散布您打算連結的函式庫的原始碼，您應該刪除大括號中的文字；否則，只需刪除大括號本身即可。

著作權 (C) [年份] [著作權持有人姓名]

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

本程式的發布是希望它會有用，但不提供任何擔保；甚至沒有適銷性或特定用途適用性的默示擔保。請參閱 GNU 通用公共授權以獲取更多詳細資訊。

您應該已收到隨本程式一起提供的 GNU 通用公共授權副本；如果沒有，請參閱 <https://gnu.dev.org.tw/licenses>。

GNU GPL 第 3 版第 7 節下的額外許可

如果您透過將本程式或任何受涵蓋的作品與 [函式庫名稱]（或該函式庫的修改版本）連結或組合，其中包含受 [函式庫授權條款名稱] 條款涵蓋的部分，則本程式的授權人授予您額外許可來傳達由此產生的作品。{非原始碼形式的此類組合的相應原始碼應包括 [函式庫名稱] 中使用的部分的原始碼以及受涵蓋作品的原始碼。}

如果您使用的是 GPLv2，您可以為授權條款提供您自己的例外。以下授權條款聲明將做到這一點。同樣，您必須將方括號中的所有文字替換為適合您程式的文字。如果不是每個人都可以散布您打算連結的函式庫的原始碼，您應該刪除大括號中的文字；否則，只需刪除大括號本身即可。

著作權 (C) [年份] [著作權持有人姓名]

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

本程式的發布是希望它會有用，但不提供任何擔保；甚至沒有適銷性或特定用途適用性的默示擔保。請參閱 GNU 通用公共授權以獲取更多詳細資訊。

您應該已收到隨本程式一起提供的 GNU 通用公共授權副本；如果沒有，請參閱 <https://gnu.dev.org.tw/licenses>。

將 [您的程式名稱] 與其他模組靜態或動態連結，是基於 [您的程式名稱] 製作組合作品。因此，GNU 通用公共授權的條款和條件涵蓋整個組合。

此外，作為一個特殊例外，[您的程式名稱] 的著作權持有人授予您許可，將 [您的程式名稱] 與根據 GNU LGPL 發布的自由軟體程式或函式庫，以及在 [函式庫授權條款名稱] 下包含在 [函式庫名稱] 標準版本中的程式碼（或此類程式碼的修改版本，授權條款不變）組合。您可以複製和散布這樣一個系統，遵循 [您的程式名稱] 的 GNU GPL 條款和其他相關程式碼的授權條款{，前提是您在 GNU GPL 要求散布原始碼時和按照 GNU GPL 的要求包含該其他程式碼的原始碼}。

請注意，製作 [您的程式名稱] 修改版本的人沒有義務為他們的修改版本授予此特殊例外；是否這樣做是他們自己的選擇。GNU 通用公共授權允許在沒有此例外的情況下發布修改版本；此例外也使得可以發布帶有此例外的修改版本。

我如何獲得程式的著作權，以便在 GPL 下發布它？ (#HowIGetCopyright)

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

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

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

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

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

現在許多大學試圖透過限制使用他們開發的知識和資訊來籌集資金，實際上表現得與商業企業沒有什麼不同。（有關此問題及其影響的一般討論，請參閱《大西洋月刊》2000 年 3 月號的「被豢養的大學」）。

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

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

您能否給我關於如何將 GPL 應用於我的程式的逐步說明？ (#CouldYouHelpApplyGPL)

請參閱GPL 指南頁面。

我聽說有人在另一個授權條款下獲得了 GPL 授權程式的副本。這有可能嗎？ (#HeardOtherLicense)

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

您副本中附帶的授權條款，假設它是由著作權持有人放入的，並且您是合法獲得該副本的，就是適用於您副本的授權條款。

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

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

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

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

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

在 GPL 下散布程式的開發者，是否可以在以後將其授權給另一方以供獨佔使用？ (#CanDeveloperThirdParty)

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

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

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

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

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

在使用 GPL 涵蓋程式的原始碼時，我是否擁有「合理使用」權？ (#GPLFairUse)

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

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

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

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

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

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

可以。如果改進是由美國政府僱員在其工作期間編寫的，那麼這些改進就屬於公共領域。但是，改進後的版本作為一個整體，仍然受 GNU GPL 約束。這種情況沒有問題。

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

GPL 對與受涵蓋作品靜態連結與動態連結的模組有不同的要求嗎？ (#GPLStaticVsDynamic)

不。將 GPL 涵蓋的作品與其他模組靜態或動態連結，是基於 GPL 涵蓋的作品製作組合作品。因此，GNU 通用公共授權的條款和條件涵蓋整個組合。另請參閱如果我將 GPL 不相容的函式庫與 GPL 軟體一起使用，會出現哪些法律問題？

LGPL 對與受涵蓋作品靜態連結與動態連結的模組有不同的要求嗎？ (#LGPLStaticVsDynamic)

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

(1) 如果您靜態連結到 LGPL 授權的函式庫，您還必須以物件（不一定是原始碼）格式提供您的應用程式，以便使用者有機會修改函式庫並重新連結應用程式。

(2) 如果您動態連結到已經存在於使用者電腦上的 LGPL 授權函式庫，您無需傳達函式庫的原始碼。另一方面，如果您自己連同您的應用程式一起傳達可執行檔 LGPL 授權函式庫，無論是靜態連結還是動態連結，您還必須以 LGPL 提供的其中一種方式傳達函式庫的原始碼。

是否有某種方法可以對人們從使用我的程式中獲得的輸出進行 GPL 授權？例如，如果我的程式用於開發硬體設計，我可以要求這些設計必須是自由的嗎？ (#GPLOutput)

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

因此，您對輸出的使用方式有發言權的唯一方法，是當輸出的大部分內容是（或多或少）從您的程式中的文字複製而來時。例如，如果我們沒有在這個特定案例中做出例外，Bison 的部分輸出（見上文）將受 GNU GPL 約束。

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

在什麼情況下，GPL 程式的輸出也受 GPL 約束？ (#WhatCaseIsOutputGPL)

一般來說，程式的輸出不受程式碼著作權的約束。因此，程式碼的授權條款不適用於輸出，無論您是將其透過管道傳輸到檔案、製作螢幕截圖、螢幕錄影或影片。

例外情況是當程式顯示來自程式的完整螢幕文字及/或藝術作品時。那麼該文字及/或藝術作品的著作權涵蓋輸出。輸出音訊的程式，例如電玩遊戲，也符合此例外情況。

如果藝術作品/音樂受 GPL 約束，那麼無論您如何複製它，GPL 都適用於您複製它時。但是，合理使用可能仍然適用。

請記住，某些程式，尤其是電玩遊戲，可能具有與底層 GPL 授權遊戲分開授權的藝術作品/音訊。在這種情況下，藝術作品/音訊的授權條款將規定影片/串流媒體可能發生的條款。另請參閱：我可以將 GPL 用於軟體以外的東西嗎？

如果我向 GPL 涵蓋的程式添加一個模組，我是否必須使用 GPL 作為我的模組的授權條款？ (#GPLModuleLicense)

GPL 聲明，整個組合程式必須在 GPL 下發布。因此，您的模組必須可在 GPL 下使用。

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

如果函式庫是在 GPL（而不是 LGPL）下發布的，這是否表示任何使用它的軟體都必須在 GPL 或與 GPL 相容的授權條款下？ (#IfLibraryIsGPL)

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

如果程式語言直譯器是在 GPL 下發布的，這是否表示為由它直譯而編寫的程式必須在與 GPL 相容的授權條款下？ (#IfInterpreterIsGPL)

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

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

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

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

我正在使用 Microsoft Visual C++ (或 Visual Basic) 編寫 Windows 應用程式，並打算以 GPL 授權發布。根據 GPL 條款，是否允許將我的程式與 Visual C++ (或 Visual Basic) 執行時期程式庫進行動態連結？ (#WindowsRuntimeAndGPL)

您可以將您的程式連結到這些程式庫，並將編譯後的程式散布給其他人。當您這樣做時，執行時期程式庫在 GPLv3 的定義下屬於「系統程式庫」。這表示您不必擔心在程式的相應原始碼中包含它們的原始碼。GPLv2 在第 3 節中提供了類似的例外情況。

您不得以編譯後的 DLL 形式與程式一起散布這些程式庫。為了防止不肖經銷商試圖利用系統程式庫的例外情況作為漏洞，GPL 規定程式庫只有在不與程式本身一起散布的情況下才能符合系統程式庫的資格。如果您將 DLL 與程式一起散布，它們將不再符合此例外情況的資格；那麼，唯一符合 GPL 的方法是提供它們的原始碼，而這是您無法做到的。

編寫只能在 Windows 上執行的自由程式是可能的，但這不是一個好主意。這些程式會被 Windows「困住」，因此對自由世界沒有任何貢獻。

為什麼原始 BSD 授權與 GPL 不相容？ (#OrigBSD)

因為它施加了 GPL 中沒有的特定要求；也就是說，對程式廣告的要求。GPLv2 第 6 節規定：

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

GPLv3 在第 10 節中也有類似的規定。廣告條款正提供了這樣一個進一步的限制，因此與 GPL 不相容。

修訂後的 BSD 授權沒有廣告條款，這消除了問題。

程式及其外掛程式在什麼情況下被視為單一組合程式？ (#GPLPlugins)

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

如果主程式動態連結外掛程式，並且它們彼此進行函數調用並共享資料結構，我們認為它們構成單一組合程式，必須將其視為主程式和外掛程式兩者的延伸。如果主程式動態連結外掛程式，但它們之間的通訊僅限於使用一些選項調用外掛程式的「main」函數並等待其返回，這是一個邊緣案例。

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

如果我編寫一個外掛程式以與 GPL 涵蓋的程式一起使用，這對我可以使用的外掛程式散布授權有什麼要求？ (#GPLAndPlugins)

請參閱此問題 以確定外掛程式和主程式在什麼情況下被視為單一組合程式，以及在什麼情況下被視為獨立作品。

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

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

請參閱此問題 以確定外掛程式和主程式在什麼情況下被視為單一組合程式，以及在什麼情況下被視為獨立程式。

如果它們形成單一組合程式，則表示 GPL 涵蓋的外掛程式與非自由主程式的組合將違反 GPL。但是，您可以透過在外掛程式的授權中新增例外條款來解決該法律問題，允許將其與非自由主程式連結。

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

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

請參閱此問題 以確定外掛程式和主程式在什麼情況下被視為單一組合程式，以及在什麼情況下被視為獨立程式。

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

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

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

您有一個 GPL 授權的程式，我想將其與我的程式碼連結以建構專有程式。我與您的程式連結的事實是否意味著我必須以 GPL 授權我的程式？ (#LinkingWithGPL)

不完全是。這表示您必須根據與 GPL 相容的授權（更精確地說，與您連結的組合中所有其他程式碼接受的一個或多個 GPL 版本相容）發布您的程式。然後，該組合本身在這些 GPL 版本下可用。

如果是這樣，我有可能獲得您的程式在較寬鬆通用公共許可證 (Lesser GPL) 下的授權嗎？ (#SwitchToLGPL)

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

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

散布旨在與核心 Linux 連結的非自由驅動程式是否違反 GPL？ (#NonfreeDriverKernelLinux)

Linux（GNU/Linux 作業系統中的核心）是根據 GNU GPL 第 2 版散布的。散布旨在與 Linux 連結的非自由驅動程式是否違反 GPL？

是的，這是一種違規行為，因為這實際上構成了一個更大的組合作品。使用者需要將各部分組裝在一起的事實並沒有真正改變任何事情。

Linux 的每位貢獻者，只要擁有程式碼實質部分的著作權，都可以執行 GPL，我們鼓勵他們每個人都採取行動對抗那些散布非自由 Linux 驅動程式的人。

我該如何僅在受控介面下允許專有模組與我的 GPL 涵蓋的程式庫連結？ (#LinkingOverControlledInterface)

將以下文字新增到套件中每個檔案的授權聲明中，在聲明檔案是根據 GNU GPL 散布的文字末尾

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

作為一個特殊例外，ABC 的著作權持有人允許您將 ABC 程式與根據 GNU LGPL 發布的自由軟體程式或程式庫，以及僅透過 ABCDEF 介面與 ABC 通訊的獨立模組組合。您可以按照 GNU GPL 對於 ABC 和相關的其他程式碼的授權條款複製和散布此類系統，前提是您在 GNU GPL 要求散布原始碼時和方式包含該其他程式碼的原始碼，並且您不修改 ABCDEF 介面。

請注意，製作 ABC 修改版本的人沒有義務為其修改版本授予此特殊例外；是否這樣做是他們的選擇。《GNU 通用公共許可證》允許發布沒有此例外的修改版本；此例外也使發布帶有此例外的修改版本成為可能。如果您修改了 ABCDEF 介面，則此例外不適用於您的 ABC 修改版本，並且您在散布修改版本時必須移除此例外。

此例外是根據《GNU 通用公共許可證》第 3 版（「GPLv3」）第 7 節的額外許可

此例外允許透過指定的介面（「ABCDEF」）與不同授權的模組連結，同時確保使用者仍然可以像通常在 GPL 下一樣收到原始碼。

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

我編寫了一個應用程式，它與許多不同的組件連結，這些組件具有不同的授權。我對我的程式施加了哪些授權要求感到非常困惑。您能告訴我可以使用的授權嗎？ (#ManyDifferentLicenses)

要回答這個問題，我們需要查看您的程式使用的每個組件的清單、該組件的授權，以及簡要說明（每個組件幾句話就足夠了）您的程式庫如何使用該組件。兩個範例是

• 為了使我的軟體工作，它必須連結到 FOO 程式庫，該程式庫在較寬鬆通用公共許可證 (Lesser GPL) 下可用。
• 我的軟體進行系統調用（使用我建構的命令列）以執行 BAR 程式，該程式在「GPL 下授權，帶有一個允許與 QUUX 連結的特殊例外」。

「聚合」與其他種類的「修改版本」之間有什麼區別？ (#MereAggregation)

「聚合」由許多獨立的程式組成，它們在同一個 CD-ROM 或其他媒體上一起散布。《GPL》允許您建立和散布聚合，即使其他軟體的授權是非自由或與 GPL 不相容。《GPL》允許您建立和散布聚合，即使其他軟體的授權是非自由或與 GPL 不相容。唯一的條件是，您不能在禁止使用者行使每個程式的個別授權將授予他們的權利的授權下發布聚合。

兩個獨立的程式和一個包含兩個部分的程式之間的界線在哪裡？這是一個法律問題，最終將由法官決定。我們認為，適當的標準取決於通訊機制（exec、管道、rpc、共享位址空間內的函數調用等）和通訊的語義（交換什麼種類的資訊）。

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

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

在確定兩個軟體是否構成單一作品時，程式碼是否在一個或多個容器中是否有任何影響？ (#AggregateContainers)

不，它們是單一作品還是聚合的分析不會因容器的介入而改變。

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

我們的律師告訴我們，為了在法庭上針對違規者以最佳立場執行 GPL，我們應該盡可能簡化程式的著作權狀態。我們透過要求每位貢獻者將貢獻的著作權轉讓給 FSF，或放棄貢獻的著作權來做到這一點。

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

當然，如果所有貢獻者都將他們的程式碼放入公共領域，那麼就沒有著作權可以執行 GPL。因此，我們鼓勵人們轉讓大型程式碼貢獻的著作權，而僅將小的變更放入公共領域。

如果您想努力在您的程式上執行 GPL，那麼您遵循類似的政策可能是個好主意。如果您想要更多資訊，請聯絡 <licensing@gnu.org>。

我可以修改 GPL 並製作修改後的授權嗎？ (#ModifyGPL)

製作 GPL 的修改版本是可能的，但這往往會產生實際的後果。

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

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

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

請不要修改 GPL，而是使用 GPL 第 3 版提供的例外機制。

如果我使用根據 GNU GPL 獲得的軟體，我是否可以修改原始程式碼成為一個新程式，然後以商業方式散布和銷售該新程式？ (#GPLCommercially)

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

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

我可以將 GPL 用於軟體以外的其他用途嗎？ (#GPLOtherThanSoftware)

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

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

LGPL 如何與 Java 一起工作？ (#LGPLJava)

請參閱本文以了解詳細資訊。 它的工作方式與設計、預期和期望的一樣。

考慮以下情況：1) X 在 GPL 下發布專案的 V1 版本。2) Y 貢獻了 V2 的開發，其中包含基於 V1 的變更和新程式碼。3) X 想要將 V2 轉換為非 GPL 授權。X 需要 Y 的許可嗎？ (#Consider)

是的。由於 Y 的版本基於 X 的 V1 版本，因此 Y 必須根據 GNU GPL 發布其版本。沒有任何規定要求 Y 同意其程式碼的任何其他授權。因此，X 在根據另一個授權發布該程式碼之前必須獲得 Y 的許可。

我想將 GPL 涵蓋的軟體納入我的專有系統中。我沒有使用該軟體的許可，除非 GPL 給予我的許可。我可以這樣做嗎？ (#GPLInProprietarySystem)

您不能將 GPL 涵蓋的軟體納入專有系統中。GPL 的目標是授予每個人複製、重新散布、理解和修改程式的自由。如果您可以將 GPL 涵蓋的軟體納入非自由系統中，那將具有使 GPL 涵蓋的軟體也成為非自由軟體的效果。

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

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

這與「納入」GPL 涵蓋的軟體之間的區別部分是實質問題，部分是形式問題。實質部分是：如果兩個程式組合在一起以至於它們有效地成為一個程式的兩個部分，那麼您就不能將它們視為兩個獨立的程式。因此，GPL 必須涵蓋整個程式。

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

如果人們散布 GPL 涵蓋的軟體，稱其為使用者知道部分是專有的系統的「一部分」，使用者可能會不確定他們關於 GPL 涵蓋的軟體的權利。但是，如果他們知道他們收到的是一個自由程式加上另一個程式，並排在一起，他們的權利將會很清楚。

根據 GPL 使用某個 GNU 程式不符合我們製作專有軟體的專案。您會為我們破例嗎？這將意味著該程式有更多使用者。 (#WillYouMakeAnException)

抱歉，我們不會破例。這是不對的。

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

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

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

我想將 GPL 涵蓋的軟體納入我的專有系統中。我可以透過在 GPL 涵蓋的部分和專有部分之間放置一個「封裝」模組，並以 GPL 相容的寬鬆許可授權（例如 X11 授權）來做到這一點嗎？ (#GPLWrapper)

不行。X11 授權與 GPL 相容，因此您可以將一個模組新增到 GPL 涵蓋的程式中，並將其置於 X11 授權下。但是，如果您要將它們都納入一個更大的程式中，那麼整個程式將包含 GPL 涵蓋的部分，因此它必須整體根據 GNU GPL 授權。

專有模組 A 僅透過 X11 授權的模組 B 與 GPL 涵蓋的模組 C 通訊的事實在法律上是不相關的；重要的是模組 C 包含在整個程式中的事實。

我在哪裡可以了解更多關於 GCC 執行時期程式庫例外的資訊？ (#LibGCCException)

GCC 執行時期程式庫例外涵蓋 libgcc、libstdc++、libfortran、libgomp、libdecnumber 和與 GCC 一起散布的其他程式庫。此例外的目的是允許人們根據自己選擇的條款散布使用 GCC 編譯的程式，即使這些程式庫的部分內容作為編譯過程的一部分包含在可執行檔中。若要了解更多資訊，請閱讀我們的 關於 GCC 執行時期程式庫例外的常見問題解答。

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

這有兩個原因。首先，一個普遍的原因。如果我們允許 A 公司製作專有檔案，並允許 B 公司散布與該檔案連結的 GPL 涵蓋的軟體，那麼效果將是在 GPL 中開一個足夠大的洞，足以讓卡車通過。這將是隱瞞 GPL 涵蓋的軟體的所有修改和延伸的原始碼的空白支票。

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

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

如果模組 Q 的授權具有與 GPL 不相容的要求，但該要求僅在 Q 單獨散布時適用，而不是在 Q 包含在更大的程式中時適用，這是否使授權與 GPL 相容？我可以將 Q 與 GPL 涵蓋的程式組合或連結嗎？ (#GPLIncompatibleAlone)

如果程式 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 涵蓋的程式的修改版本嗎？ (#ModifiedJustBinary)

不行。GPL 的重點是所有修改版本都必須是自由軟體——這尤其意味著，修改版本的原始碼可供使用者使用。

我只是從網路上下載了二進位檔。如果我散布副本，我是否也必須取得原始碼並散布原始碼？ (#UnchangedJustBinary)

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

我想透過實體媒體散布二進位檔，但不附帶原始碼。我可以透過 FTP 提供原始碼嗎？ (#DistributeWithSourceOnInternet)

GPL 第 3 版允許這樣做；請參閱選項 6(b) 以了解完整詳細資訊。在第 2 版下，您當然可以自由地透過 FTP 提供原始碼，大多數使用者也會從那裡取得原始碼。但是，如果他們中的任何一個人寧願透過郵件在實體媒體上獲得原始碼，您則必須提供。

如果您透過 FTP 散布二進位檔，您應該透過 FTP 散布原始碼。

我的朋友獲得了一個附帶提供原始碼報價的 GPL 涵蓋的二進位檔，並為我製作了一個副本。我自己可以使用該報價來獲得原始碼嗎？ (#RedistributedBinariesGetSource)

是的，您可以。該報價必須對擁有其隨附的二進位檔副本的每個人開放。這就是為什麼 GPL 規定您的朋友必須在向您提供二進位檔副本的同時向您提供報價副本——以便您可以利用它。

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

是的。第 6(d) 節允許這樣做。但是，您必須提供人們可以遵循以獲得原始碼的明確說明，並且您必須注意確保原始碼在您散布目標程式碼的期間內保持可用。

我想以二進位形式散布 GPL 涵蓋的程式的延伸版本。散布原始版本的原始碼是否足夠？ (#DistributeExtendedBinary)

不，您必須提供與二進位檔相對應的原始碼。相應原始碼表示使用者可以從中重建相同二進位檔的原始碼。

自由軟體的其中一部分理念是使用者應該能夠存取他們使用的程式的原始碼。那些使用您的版本的人應該能夠存取您的版本的原始碼。

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

我想散布二進位檔，但散布完整原始碼很不方便。如果我向使用者提供與「標準」版本的差異以及二進位檔，可以嗎？ (#DistributingSourceIsInconvenient)

這是一個善意的請求，但這種提供原始碼的方法並沒有真正完成工作。

一年後想要原始碼的使用者可能無法在當時從另一個網站獲得正確的版本。標準散布網站可能有一個較新的版本，但相同的差異可能不適用於該版本。

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

我可以讓二進位檔在網路伺服器上可用，但僅向訂購的人發送原始碼嗎？ (#AnonFTPAndSendSources)

如果您在網路伺服器上提供目標程式碼，您也必須在網路伺服器上提供相應的原始碼。最簡單的方法是將它們發布在同一個伺服器上，但如果您願意，您也可以提供從另一個伺服器甚至版本控制系統取得原始碼的說明。無論您做什麼，原始碼都應該與目標程式碼一樣容易存取。所有這些都在 GPLv3 的第 6(d) 節中規定。

您提供的原始碼必須與二進位檔完全對應。特別是，您必須確保它們適用於相同版本的程式——而不是較舊的版本，也不是較新的版本。

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

您不必確保這一點。只要您使原始碼和二進位檔可用，以便使用者可以看到可用的內容並取得他們想要的內容，您就完成了對您的要求。是否下載原始碼取決於使用者。

我們對再發行者的要求旨在確保使用者可以取得原始碼，而不是強迫使用者下載他們不需要的原始碼。

GPL 是否要求我提供的原始碼，必須能夠建置出與我發行的二進位檔案完全相同的雜湊值？ (#MustSourceBuildToMatchExactHashOfBinary)

完整對應的原始碼指的是二進位檔案所由來的原始碼，但這並不表示您的工具必須能夠建立一個與您發行的二進位檔案完全相同的雜湊值的二進位檔案。在某些情況下，從原始碼建置出與發行的二進位檔案完全相同的雜湊值的二進位檔案，可能（幾乎）是不可能的——請考慮以下範例：系統可能會在二進位檔案中放入時間戳記；或者程式可能是在不同的（甚至未發布的）編譯器版本下建置的。

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

GPL 允許任何人製作修改版本並使用它，而無需將其散布給他人。這間公司所做的事情是這種情況的特例。因此，該公司不必發布修改後的原始碼。當修改後的程式根據 GNU Affero GPL 的條款授權時，情況就不同了。

將此與另一種情況比較，在該情況下，網站包含或連結到當使用者訪問網站時，會散布給使用者的獨立 GPL 授權程式（通常以 JavaScript 編寫，但也使用其他語言）。在這種情況下，根據 GPL 的條款，必須向使用者發布正在散布的程式的原始碼。

一間公司正在網站上執行根據 GNU Affero GPL (AGPL) 授權的程式的修改版本。AGPL 是否規定他們必須發布其修改後的原始碼？ (#UnreleasedModsAGPL)

GNU Affero GPL 要求軟體的修改版本，必須為透過電腦網路與其互動的所有使用者，提供接收原始碼的機會。該公司正在做的事情屬於這個範疇，因此該公司必須發布修改後的原始碼。

在一個組織或公司內部製作和使用多個副本是否構成「散布」？ (#InternalDistribution)

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

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

如果有人偷了一張包含 GPL 授權程式版本的 CD，GPL 是否賦予竊賊重新散布該版本的權利？ (#StolenCopy)

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

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

如果一家公司將其他開發人員的 GPL 授權作品副本作為商業機密散布給我，該怎麼辦？ (#TradeSecretRelease)

該公司已違反 GPL，並且必須停止散布該程式。請注意這與上述盜竊案例的不同之處；當副本被盜時，公司並非有意散布副本，因此在該案例中，公司並未違反 GPL。

如果一家公司將其自己的 GPL 授權作品副本作為商業機密散布給我，該怎麼辦？ (#TradeSecretRelease2)

如果散布的程式未包含任何其他人的 GPL 授權作品，那麼該公司並未違反 GPL（有關更多資訊，請參閱「GPL 授權程式的開發者是否受 GPL 約束？」）。但是，它對您可以對該程式做什麼提出了兩個矛盾的聲明：您可以重新散布它，以及您不能重新散布它。在您接受副本之前，要求澄清該程式的使用條款是有道理的。

為什麼某些 GNU 函式庫是以一般 GPL 而不是寬鬆 GPL 發布的？ (#WhySomeGPLAndNotLGPL)

對於任何特定的函式庫使用寬鬆 GPL，都構成對自由軟體的退讓。這表示我們部分放棄了捍衛使用者自由的嘗試，以及分享在 GPL 授權軟體之上建構之物的某些要求。就其本身而言，這些都是更糟的改變。

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

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

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

為什麼程式應該寫「GPL 第 3 版或任何更新版本」？ (#VersionThreeOrLater)

我們不時地，每隔幾年，就會更改 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。

使用聲明特定程式只能在最新版本的 GNU GPL 下使用的授權條款，是個好主意嗎？ (#OnlyLatestVersion)

您不應該這樣做的原因是，有一天可能會導致自動撤回使用者先前擁有的某些權限。

假設一個程式在 2000 年以「最新 GPL 版本」發布。當時，人們可以在 GPLv2 下使用它。在我們於 2007 年發布 GPLv3 的那天，每個人都會突然被迫改為在 GPLv3 下使用它。

有些使用者甚至可能不知道 GPL 第 3 版——但他們將被要求使用它。他們可能僅僅因為沒有收到消息，就可能在無意中違反了程式的授權條款。這是一種對待人們的糟糕方式。

我們認為，除了因違規行為外，收回已授予的權限是錯誤的。如果您的自由可以被撤銷，那麼它就不是真正的自由。因此，如果您在某個授權條款版本下獲得程式版本的副本，您應該始終擁有該授權條款版本授予的權利。以「GPL 第 N 版或任何更新版本」發布，維護了該原則。

為什麼你們不對手冊使用 GPL？ (#WhyNotGPLForManuals)

可以對手冊使用 GPL，但 GNU 自由文檔許可證 (GFDL) 更適合手冊。

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

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

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

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

GPL 如何應用於字型？ (#FontException)

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

若要使用此例外，請將此文本添加到套件中每個檔案的授權聲明中（在可能的範圍內），放在說明該檔案是根據 GNU GPL 散布的文本末尾

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

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

範本的份量很小，不值得使用著作權保護。通常在小作品上使用著作權是無害的，但範本是一種特殊情況，因為它們與應用程式使用者提供的資料結合在一起，並且組合是散布的。因此，我們建議您根據簡單的許可條款授權您的範本。

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

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

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

我可以使用非自由工具開發的程式，以 GPL 發布嗎？ (#NonFreeTools)

您用於編輯原始碼、編譯原始碼、研究原始碼或記錄原始碼的程式，通常對於有關該原始碼授權的問題沒有影響。

但是，如果您將非自由函式庫與原始碼連結，那將是您需要處理的問題。這並不排除根據 GPL 發布原始碼，但如果這些函式庫不符合「系統函式庫」的例外情況，您應該附加明確的聲明，授權將您的程式與它們連結。關於使用與 GPL 不相容的函式庫的常見問題解答條目，提供了更多關於如何執行此操作的資訊。

是否有 GPL 的其他語言翻譯版本？ (#GPLTranslations)

如果有 GPL 的英文以外的其他語言翻譯版本，將會很有用。人們甚至編寫了翻譯版本並發送給我們。但我們不敢批准它們作為正式有效版本。這帶來了極大的風險，我們不敢接受。

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

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

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

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

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

• 將人們導向非官方翻譯版本。這表示我們允許人們編寫 GPL 的翻譯版本，但我們不批准它們作為法律上有效且具有約束力的版本。

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

  此 GPL 翻譯版本是非正式的，並且未經自由軟體基金會正式批准為有效版本。為了完全確定允許的事項，請參閱原始 GPL（英文版本）。

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

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

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

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

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

如果程式語言直譯器具有與 GPL 不相容的授權條款，我可以在其上執行 GPL 授權程式嗎？ (#InterpreterIncompat)

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

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

因此，如果這些設施是以與 GPL 不相容的授權條款發布的，情況就像以任何其他方式與與 GPL 不相容的函式庫連結一樣。這表示

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

誰有權執行 GPL？ (#WhoHasThePower)

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

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

在物件導向語言（如 Java）中，如果我使用一個未經修改的 GPL 授權類別，並對其進行子類別化，GPL 會以何種方式影響更大的程式？ (#OOPLang)

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

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

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

有些函式庫僅根據 GNU GPL 發布；您必須使用與 GPL 相容的授權條款才能使用這些函式庫。但這些通常是更專業的函式庫，您在另一個平台上不太可能有類似的東西，因此您可能不會發現自己想要使用這些函式庫進行簡單的移植。

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

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

我剛剛發現一家公司擁有 GPL 授權程式的副本，並且取得它需要花錢。他們沒有在網際網路上提供它，難道不是違反 GPL 嗎？ (#CompanyGPLCostsMoney)

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

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

我可以發布一個程式，其授權條款聲明您可以根據 GPL 散布其修改版本，但您不能根據 GPL 散布原始版本本身嗎？ (#ReleaseNotOriginal)

不行。這種授權條款會是自相矛盾的。讓我們看看它對我作為使用者的影響。

假設我從原始版本（稱之為版本 A）開始，添加一些程式碼（假設是 1000 行），並根據 GPL 發布該修改版本（稱之為版本 B）。GPL 聲明任何人都可以再次更改版本 B，並根據 GPL 發布結果。因此，我（或其他人）可以刪除那 1000 行，產生版本 C，其程式碼與版本 A 相同，但受 GPL 約束。

如果您試圖阻止該路徑，在授權條款中明確聲明我不允許透過從版本 B 中刪除這些行，來根據 GPL 複製與版本 A 相同的東西，實際上，授權條款現在表示我不能以 GPL 允許的所有方式充分使用版本 B。換句話說，授權條款實際上並不允許使用者根據 GPL 發布像 B 這樣的修改版本。

將副本轉移到多數股權擁有且受控制的子公司是否構成散布？ (#DistributeSubsidiary)

將副本轉移到或從該子公司轉移是否構成「散布」，是根據適當管轄區的著作權法在每個案例中決定的事項。GPL 沒有也不可能凌駕於當地法律之上。美國著作權法在這一點上並非完全清楚，但似乎不認為這是散布。

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

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

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

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

我想將 GPL 授權軟體與某種安裝軟體捆綁在一起。該安裝程式是否需要具有與 GPL 相容的授權條款？ (#GPLCompatInstaller)

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

有些 GPL 授權軟體的散布商，在其總括 EULA 中或作為其下載過程的一部分，要求我「聲明並保證」我位於美國，或者我打算根據相關的出口管制法律散布軟體。他們為什麼要這樣做？這是否違反了這些散布商在 GPL 下的義務？ (#ExportWarranties)

這並未違反 GPL。這些散布商（幾乎所有都是銷售自由軟體散布和相關服務的商業企業）試圖降低自身的法律風險，而不是控制您的行為。美國的出口管制法律可能會讓他們承擔責任，如果他們明知故犯地將軟體出口到某些國家/地區，或者如果他們將軟體提供給他們知道會進行此類出口的各方。透過要求其客戶和他們散布軟體的其他對象提供這些聲明，他們可以保護自己，以防監管機構稍後詢問他們，他們對其散布的軟體最終會流向何處了解多少。他們並未限制您可以對軟體做什麼，只是防止自己因您所做的任何事情而受到指責。由於他們沒有對軟體施加額外的限制，因此他們沒有違反 GPLv3 的第 10 節或 GPLv2 的第 6 節。

FSF 反對將美國出口管制法律應用於自由軟體。這些法律不僅與軟體自由的總體目標不相容，而且沒有達到合理的政府目的，因為自由軟體目前並且應該始終可以從幾乎每個國家的各方獲得，包括那些沒有出口管制法律且不參與美國主導的貿易禁運的國家/地區。因此，就我們而言，沒有任何國家的政府實際上因美國出口管制法律而被剝奪自由軟體，而任何國家的公民都不應被剝奪自由軟體，無論其政府的政策如何。可以從我們這裡獲得 FSF 發布的所有 GPL 授權軟體的副本，而無需聲明您居住在哪裡或您打算做什麼。同時，FSF 理解位於美國的商業散布商希望遵守美國法律的意願。他們有權選擇向誰散布自由軟體的特定副本；除非他們添加超出 GPL 允許範圍的合約限制，否則行使該權利並不違反 GPL。

我可以在如果客戶沒有繼續支付訂閱費就會停止運作的裝置上，使用 GPL 授權軟體嗎？ (#SubscriptionFee)

不行。在這種情況下，保持支付費用的要求限制了使用者執行程式的能力。這是 GPL 之上的額外要求，並且授權條款禁止它。

我如何從 (L)GPLv2 升級到 (L)GPLv3？ (#v3HowToUpgrade)

首先，將新版本的授權條款包含在您的套件中。如果您在專案中使用 LGPLv3，請務必同時包含 GPLv3 和 LGPLv3 的副本，因為 LGPLv3 現在被編寫為一組基於 GPLv3 的額外許可。

其次，將您所有現有的 v2 授權聲明（通常在每個檔案的頂部）替換為 GNU 授權條款操作指南上提供的新建議文本。它更具未來性，因為它不再包含 FSF 的郵政郵寄地址。

當然，任何描述性文本（例如在 README 中）中談到套件授權條款的內容，也應適當地更新。

GPLv3 如何使 BitTorrent 散布更容易？ (#BitTorrent)

由於 GPLv2 是在軟體的點對點散布普及之前編寫的，因此當您以這種方式共享程式碼時，很難滿足其要求。在 BitTorrent 上散布 GPLv2 物件程式碼時，確保您合規的最佳方法是在同一個 torrent 中包含所有對應的原始碼，但這將會非常昂貴。

GPLv3 以兩種方式解決了這個問題。首先，下載此 torrent 並作為該過程的一部分將資料發送給他人的人，無需執行任何操作。這是因為第 9 節聲明「僅僅由於使用點對點傳輸接收副本而發生的受保護作品的輔助傳播，同樣不需要接受 [授權條款]。」

其次，GPLv3 的第 6 節 (e) 旨在為散布商——最初散布 torrent 的人——提供一種清晰直接的方式來提供原始碼，方法是告訴接收者原始碼在公共網路伺服器上的可用位置。這確保了每個想要取得原始碼的人都可以這樣做，並且對於散布商來說幾乎沒有麻煩。

什麼是 Tivo 化？GPLv3 如何防止它？ (#Tivoization)

有些裝置使用可以升級的自由軟體，但設計成不允許使用者修改該軟體。有很多不同的方法可以做到這一點；例如，有時硬體會對已安裝的軟體進行校驗和，如果它與預期的簽名不符，則會關閉。製造商透過向您提供原始碼來遵守 GPLv2，但您仍然沒有自由修改您正在使用的軟體。我們將這種做法稱為 Tivo 化。

當人們散布包含 GPLv3 下軟體的使用者產品時，第 6 節要求他們向您提供修改該軟體所需的資訊。「使用者產品」是許可證中特別定義的術語；使用者產品的範例包括可攜式音樂播放器、數位錄影機和家庭安全系統。

GPLv3 是否禁止 DRM？ (#DRMProhibited)

它沒有禁止；您可以使用根據 GPLv3 發布的程式碼來開發您喜歡的任何類型的 DRM 技術。但是，如果您這樣做，第 3 節聲明該系統將不被視為有效的技術「保護」措施，這表示如果有人破解 DRM，她也可以自由散布她的軟體，而不受 DMCA 和類似法律的阻礙。

與往常一樣，GNU GPL 不限制人們在軟體中做什麼，它只是阻止他們限制他人。

我可以使用 GPL 授權硬體嗎？ (#GPLHardware)

任何可以受著作權保護的材料都可以根據 GPL 授權。GPLv3 也可用於授權受其他類似著作權法律保護的材料，例如半導體光罩。因此，舉例來說，您可以根據 GPL 發布物理物體或電路的圖紙。

在許多情況下，著作權不涵蓋從圖紙製作實體硬體。在這些情況下，無論您使用什麼授權條款，您對圖紙的授權都無法對製作或銷售實體硬體施加任何控制。當著作權確實涵蓋製作硬體時，例如 IC 光罩，GPL 會以有用的方式處理這種情況。

我使用公開金鑰密碼學來簽署我的程式碼，以確保其真實性。GPLv3 是否真的強迫我發布我的私密簽署金鑰？ (#GiveUpKeys)

否。您唯一需要釋出簽章金鑰的情況，是當您在使用者產品中傳達受 GPL 規範的軟體，且其硬體在運作前會檢查該軟體是否具有有效的加密簽章。在該特定情況下，您必須應要求向擁有該裝置的任何人提供金鑰，以簽署並在其裝置上安裝修改後的軟體，使其能夠運行。如果每個裝置實例使用不同的金鑰，那麼您只需要為每位購買者提供該實例的金鑰即可。

GPLv3 是否要求投票者能夠修改投票機中運行的軟體？ (#v3VotingMachine)

否。散布包含在 GPLv3 授權條款下軟體的設備公司，最多僅需向持有目標碼副本的人提供該軟體的原始碼和安裝資訊。使用投票機的投票者（如同任何其他資訊站）並未取得投票機的所有權，即使是暫時的也沒有，因此投票者也未取得其中二進位軟體的所有權。

但請注意，投票是非常特殊的情況。僅僅因為電腦中的軟體是自由軟體，並不代表您可以信任該電腦進行投票。我們認為電腦不可信任於投票。投票應以紙本進行。

GPLv3 是否有「專利報復條款」？ (#v3PatentRetaliation)

實際上，是的。第 10 節禁止傳達軟體的人對其他被授權者提起專利訴訟。如果有人真的這樣做了，第 8 節說明他們將如何失去其授權以及隨之而來的任何專利授權。

我是否可以在與 GPL 不相容的授權條款下授權的文件中使用受 GPL 規範的原始碼片段？ (#SourceCodeInDocumentation)

如果這些片段夠小，您可以根據合理使用或類似法律將其納入，那麼可以。否則，不行。

GPLv3 第 6 節的開頭說，我可以「根據第 4 節和第 5 節的條款」傳達目標碼形式的受涵蓋作品，前提是我也符合第 6 節的條件。這是什麼意思？ (#v3Under4and5)

這表示當您傳達目標碼時，所有您在傳達原始碼時必須遵守的許可和條件也適用：您可以收取費用，您必須保持著作權聲明完整等等。

我的公司擁有許多專利。多年來，我們以「GPL 第 2 版或任何後續版本」的條款貢獻程式碼到專案中，而該專案本身也以相同的條款發布。如果使用者決定根據 GPLv3 取得專案的程式碼（包含我的貢獻），這是否表示我已自動授予該使用者 GPLv3 的明確專利授權？ (#v2OrLaterPatentLicense)

否。當您傳達受 GPL 規範的軟體時，您必須遵循特定版本的授權條款和條件。當您這樣做時，該版本會定義您所承擔的義務。如果使用者也可以選擇使用 GPL 的後續版本，那僅僅是他們擁有的額外許可，並不要求您也履行 GPL 後續版本的條款。

請勿將此理解為您可以用您的專利威脅社群。在許多國家/地區，根據 GPLv2 散布軟體會向接收者提供隱含的專利授權，以行使他們在 GPL 下的權利。即使沒有，任何考慮積極執行其專利的人都是社群的敵人，我們將自衛反擊此類攻擊。

如果我散布一個連結到我修改過的 LGPLv3 規範函式庫的專有程式，那麼為了確定我所授予的明確專利授權範圍，「貢獻者版本」是指什麼？僅僅是該函式庫，還是整個組合？ (#LGPLv3ContributorVersion)

「貢獻者版本」僅指您版本的函式庫。

GPLv3 與 GPLv2 相容嗎？ (#v2v3Compatibility)

否。從 GPLv2 到 GPLv3，許多要求都已更改，這表示 GPLv2 的精確要求並未出現在 GPLv3 中，反之亦然。例如，GPLv3 的終止條件比 GPLv2 的條件寬鬆得多，因此與 GPLv2 的終止條件不同。

由於這些差異，這兩個授權條款不相容：如果您嘗試將根據 GPLv2 發布的程式碼與根據 GPLv3 發布的程式碼組合，您將違反 GPLv2 的第 6 節。

但是，如果程式碼是根據 GPL「第 2 版或後續版本」發布的，則與 GPLv3 相容，因為 GPLv3 是其允許的選項之一。

GPLv2 是否有關於交付安裝資訊的要求？ (#InstInfo)

GPLv3 明確要求重新散布時包含完整的必要「安裝資訊」。GPLv2 沒有使用該術語，但它確實要求重新散布時包含 用於控制可執行檔的編譯和安裝的腳本 以及完整且對應的原始碼。這涵蓋了 GPLv3 所謂「安裝資訊」的部分但非全部內容。因此，GPLv3 關於安裝資訊的要求更為嚴格。

「治癒」違反 GPLv3 的行為是什麼意思？ (#Cure)

治癒違規行為表示調整您的實務做法，以符合授權條款的要求。

GPLv3 中的保固和責任免責聲明似乎是針對美國法律而定的。我可以在我自己的程式碼中添加我自己的免責聲明嗎？ (#v3InternationalDisclaimers)

可以。第 7 節授權您添加自己的免責聲明，特別是 7(a) 條。

我的程式具有非視覺性質的互動式使用者介面。我該如何遵守 GPLv3 中的「適當法律聲明」要求？ (#NonvisualLegalNotices)

您只需要確保使用者可以在您的介面中輕鬆取得「適當法律聲明」即可。例如，如果您編寫了一個音訊介面，您可以加入一個大聲朗讀聲明的命令。

如果我將受 GPLv3 規範的程式副本給我在公司的同事，我是否已將該副本「傳達」給該同事？ (#v3CoworkerConveying)

只要您們都是在公司工作中使用該軟體，而不是個人使用，那麼答案是否定的。這些副本屬於公司，不屬於您或您的同事。這種複製是傳播，而不是傳達，因為公司並未向其他人提供副本。

如果我散布受 GPLv3 規範的程式，我可以提供在使用者修改程式後失效的保固嗎？ (#v3ConditionalWarranty)

可以。正如裝置在使用者修改其內部軟體後不需要提供保固一樣，您也不需要提供涵蓋某人可能對受 GPLv3 規範的軟體進行的所有可能活動的保固。

為什麼您決定將 GNU Affero GPLv3 作為單獨的授權條款編寫？ (#SeparateAffero)

GPLv3 的早期草案允許授權者在第 7 節中添加類似 Affero 的發布原始碼要求。但是，一些開發和依賴自由軟體的公司認為此要求過於繁重。他們希望避免使用具有此要求的程式碼，並對檢查程式碼是否符合此附加要求的管理成本表示擔憂。透過將 GNU Affero GPLv3 作為單獨的授權條款發布，並在其和 GPLv3 中加入允許這些授權條款下的程式碼相互連結的條款，我們實現了所有最初的目標，同時也更容易確定哪些程式碼具有原始碼發布要求。

為什麼您在 GPLv3 中發明了新術語「傳播」和「傳達」？ (#WhyPropagateAndConvey)

GPLv2 中使用的術語「散布」是借用自美國著作權法。多年來，我們了解到某些司法管轄區在其自身的著作權法中使用了相同的詞，但賦予了不同的含義。我們發明了這些新術語，以盡可能清楚地表達我們的意圖，無論授權條款在何處被解釋。它們在世界任何著作權法中都未使用，我們直接在授權條款中提供其定義。

我想根據 GPL 授權我的程式碼，但我也想明確表示它不能用於軍事和/或商業用途。我可以這樣做嗎？ (#NoMilitary)

否，因為這兩個目標相互矛盾。GNU GPL 的設計目的明確是為了防止添加進一步的限制。GPLv3 允許在第 7 節中加入非常有限的一組限制，但使用者可以移除任何其他添加的限制。

更廣泛地說，限制誰可以使用程式或將程式用於何種用途的授權條款不是自由軟體授權條款。

GPLv3 中的「傳達」與 GPLv2 中「散布」的意思相同嗎？ (#ConveyVsDistribute)

是的，大致相同。在執行 GPLv2 的過程中，我們了解到某些司法管轄區在其自身的著作權法中使用了「散布」一詞，但賦予了不同的含義。我們發明了一個新術語，以清楚地表達我們的意圖，並避免因這些差異可能導致的任何問題。

GPLv3 將「向公眾提供」作為傳播的一個例子。這是什麼意思？向公眾提供是一種傳達形式嗎？ (#v3MakingAvailable)

「向公眾提供」的一個例子是將軟體放在公共網站或 FTP 伺服器上。在您執行此操作後，可能需要經過一段時間才會有人真正從您那裡取得軟體，但因為這可能立即發生，所以您也需要立即履行 GPL 的義務。因此，我們將傳達定義為包含此活動。

既然散布和向公眾提供是傳播的形式，同時在 GPLv3 中也屬於傳達，那麼有哪些不構成傳達的傳播範例？ (#PropagationNotConveying)

為自己製作軟體副本是不構成傳達的主要傳播形式。您可能會這樣做是為了在多部電腦上安裝軟體，或是為了製作備份。

將受 GPL 規範的二進位檔案預先連結到系統上的各種函式庫以最佳化其效能，是否算作修改？ (#Prelinking)

否。預先連結是編譯過程的一部分；它不會引入任何超出編譯其他方面的授權要求。如果您被允許將程式連結到函式庫，那麼也可以對它們進行預先連結。如果您散布預先連結的目標碼，您需要遵守第 6 節的條款。

如果有人在筆記型電腦上安裝了受 GPL 規範的軟體，然後將該筆記型電腦借給朋友而未提供該軟體的原始碼，他們是否違反了 GPL？ (#LaptopLoan)

否。在我們調查此問題的司法管轄區中，這種借貸行為不構成傳達。筆記型電腦的所有者不會承擔 GPL 下的任何義務。

假設有兩家公司試圖規避提供安裝資訊的要求，一家公司發布簽署的軟體，另一家公司發布僅運行第一家公司簽署軟體的使用者產品。這是否違反 GPLv3？ (#TwoPartyTivoization)

是的。如果兩方試圖協同合作以規避 GPL 的要求，他們都可能因著作權侵權行為而被追究責任。由於傳達的定義明確包含會使某人對次要侵權行為負責的活動，因此情況尤其如此。

如果我在 FTP 伺服器上提供二進位檔案，並透過版本控制系統（如 CVS 或 Subversion）中原始碼儲存庫的連結提供原始碼，我是否符合 GPLv3 的規定？ (#SourceInCVS)

只要原始碼簽出過程不會變得繁瑣或受到其他限制，這是可以接受的。任何可以下載您的目標碼的人也應該能夠使用公開可用的自由軟體用戶端從您的版本控制系統中簽出原始碼。應向使用者提供清晰且方便的指示，說明如何取得他們下載的確切目標碼的原始碼——畢竟，他們可能不一定想要最新的開發程式碼。

在使用者產品中傳達受 GPLv3 規範的軟體的人，是否可以使用遠端證明來阻止使用者修改該軟體？ (#RemoteAttestation)

否。安裝資訊的定義（當軟體在使用者產品中傳達時必須隨原始碼提供）明確指出：「資訊必須足以確保修改後的目標碼的持續運作在任何情況下都不會僅僅因為進行了修改而受到阻止或干擾。」如果裝置以某種方式使用遠端證明，則安裝資訊必須為您提供某種方法，讓您修改後的軟體能夠將自身報告為合法。

GPLv3 中的「跨網路通訊的規則和協定」是什麼意思？ (#RulesProtocols)

這指的是關於您可以透過網路傳送的流量的規則。例如，如果您每天可以傳送到伺服器的請求數量或您可以在某處上傳的檔案大小有限制，如果您不遵守這些限制，您對這些資源的存取可能會被拒絕。

這些規則不包含任何與跨網路傳輸資料沒有直接關係的內容。例如，如果網路上的伺服器向您的裝置傳送使用者訊息，僅僅因為您修改了軟體使其不顯示訊息，您對網路的存取也不得被拒絕。

根據 GPLv3 提供安裝資訊的散布者，不需要為產品提供「支援服務」。您所指的「支援服務」是什麼類型？ (#SupportService)

這包括許多裝置製造商提供的，協助您安裝、使用產品或排除產品故障的服務。如果裝置依賴於網路服務或類似技術才能正常運作，則這些服務通常仍應適用於修改後的版本，但須遵守第 6 節中關於網路存取的條款。

在 GPLv3 和 AGPLv3 中，「儘管本授權條款有任何其他規定」是什麼意思？ (#v3Notwithstanding)

這僅表示以下條款優先於授權條款中可能與之衝突的任何其他條款。例如，如果沒有這段文字，有些人可能會聲稱您不能將 GPLv3 下的程式碼與 AGPLv3 下的程式碼組合，因為 AGPL 的附加要求將被歸類為 GPLv3 第 7 節下的「進一步限制」。這段文字清楚地表明我們預期的解釋是正確的，您可以進行組合。

這段文字僅解決授權條款不同條款之間的衝突。當兩個條件之間沒有衝突時，您必須同時滿足這兩個條件。這些段落並未授予您可以無視授權條款其餘部分的許可——相反，它們正在劃分非常有限的例外情況。

在 AGPLv3 下，當我根據第 13 節修改程式時，它必須提供什麼對應原始碼？ (#AGPLv3CorrespondingSource)

「對應原始碼」在授權條款的第 1 節中定義，您應該提供其中列出的內容。因此，如果您的修改版本依賴於其他授權條款（例如 Expat 授權條款或 GPLv3）下的函式庫，「對應原始碼」應包含這些函式庫（除非它們是系統函式庫）。如果您修改了這些函式庫，您必須提供您修改後的原始碼。

第 13 節第一段的最後一句話僅旨在強化大多數人自然而然會假設的內容：即使與 GPLv3 下的程式碼的組合是透過第 13 節中的特殊例外處理的，「對應原始碼」仍應包含以這種方式與程式組合的程式碼。這句話並不表示您僅需要提供 GPLv3 規範下的原始碼；而是表示此類程式碼並未從「對應原始碼」的定義中排除。

在 AGPLv3 中，什麼算作「透過電腦網路與 [軟體] 遠端互動」？ (#AGPLv3InteractingRemotely)

如果程式明確設計為接受使用者請求並透過網路發送回應，則它符合這些標準。屬於此類別的程式的常見範例包括網站和郵件伺服器、互動式網頁應用程式以及線上遊戲伺服器。

如果程式並非明確設計為透過網路與使用者互動，而是在碰巧這樣做的環境中運行，則它不屬於此類別。例如，僅僅因為使用者透過 SSH 或遠端 X 工作階段運行應用程式，應用程式不需要提供原始碼。

GPLv3 的「您」的概念與 Apache License 2.0 中「法人實體」的定義相比如何？ (#ApacheLegalEntity)

它們實際上是相同的。「法人實體」在 Apache License 2.0 中的定義在各種類型的法律協議中非常標準，以至於如果法院在沒有明確定義的情況下沒有以相同的方式解釋該術語，那將非常令人驚訝。我們完全期望他們在查看 GPLv3 並考慮誰有資格成為被授權者時也會這樣做。

在 GPLv3 中，「程式」指的是什麼？是指根據 GPLv3 發布的每個程式嗎？ (#v3TheProgram)

術語「程式」指的是根據 GPLv3 授權，且特定被授權者從上游授權者或散布者那裡收到的特定作品。「程式」是您在給定的 GPLv3 授權實例中收到的特定軟體作品，正如您收到的那樣。

「程式」不能意指「根據 GPLv3 授權的所有作品」；這種解釋在許多方面都沒有意義。我們發布了一份關於術語「程式」的分析，供那些想了解更多相關資訊的人參考。

如果我僅製作受 GPL 規範的程式副本並運行它們，而不將它們散布或傳達給他人，則授權條款對我有什麼要求？ (#NoDistributionRequirements)

沒有任何要求。GPL 對此活動沒有任何條件限制。

如果某些網路用戶端軟體是根據 AGPLv3 發布的，它是否必須能夠向與之互動的伺服器提供原始碼？ (#AGPLv3ServerAsUser)

AGPLv3 要求程式向「所有透過電腦網路遠端與其互動的使用者」提供原始碼。您稱程式為「用戶端」還是「伺服器」並不重要，您需要問的問題是，是否可以合理預期有人會透過網路遠端與程式互動。

對於運行根據 AGPL 授權的代理伺服器的軟體，我該如何向與該程式碼互動的使用者提供原始碼？ (#AGPLProxy)

對於代理伺服器上的軟體，您可以透過向此類代理的使用者傳遞訊息的正常方法提供原始碼。例如，Web 代理可以使用登陸頁面。當使用者最初開始使用代理時，您可以將他們定向到一個包含原始碼提供以及您選擇提供的任何其他資訊的頁面。

AGPL 規定您必須向「所有使用者」發出要約。如果您知道某個使用者已經看過針對當前軟體版本的要約，則不必再次向該使用者重複發出要約。

各種 GNU 授權條款彼此之間如何相容？ (#AllCompatibility)

各種 GNU 授權條款彼此之間享有廣泛的相容性。您可能無法將兩種授權條款下的程式碼組合的唯一情況是，當您想要將僅在較舊版本授權條款下的程式碼與在較新版本下的程式碼一起使用時。

以下是各種 GNU 授權條款組合的詳細相容性矩陣，為特定情況提供易於使用的參考。它假設其他人已根據這些授權條款之一編寫了一些軟體，並且您想以某種方式將其中的程式碼合併到您要發布的專案中（無論是您自己的原創作品，還是其他人軟體的修改版本）。在表格頂部的欄中找到您專案的授權條款，並在左側的列中找到其他程式碼的授權條款。它們相交的單元格將告訴您是否允許這種組合。

當我們說「複製程式碼」時，我們的意思就是這樣：您從一個來源取得一段程式碼，無論是否經過修改，並將其插入您自己的程式中，從而形成一個基於第一段程式碼的作品。「使用函式庫」表示您沒有直接複製任何原始碼，而是透過連結、匯入或其他典型的機制與其互動，這些機制在您編譯或運行程式碼時將來源連結在一起。

矩陣中每個標示 GPLv3 的地方，關於相容性的陳述對於 AGPLv3 也同樣適用。

跳過相容性矩陣

跳過註腳

1：在這種情況下合併程式碼時，您必須遵守 GPLv2 的條款。您不能利用 GPL 後續版本中的條款。

2：雖然您可以根據 GPLv2 或後續版本發布您的原創作品，和/或您根據 GPLv2 或後續版本收到的作品的修改版本，但您正在使用的僅限 GPLv2 的程式碼必須保持僅限 GPLv2。只要您的專案依賴於該程式碼，您將無法將您自己的程式碼的授權條款升級到 GPLv3 或後續版本，並且整個作品（您的專案和其他程式碼的任何組合）只能根據 GPLv2 的條款傳達。

3：如果您有能力根據 GPLv2 或任何後續版本發布專案，您可以選擇根據 GPLv3 或任何後續版本發布它——一旦您這樣做，您就可以合併根據 GPLv3 發布的程式碼。

4：如果您有能力根據 LGPLv2.1 或任何後續版本發布專案，您可以選擇根據 LGPLv3 或任何後續版本發布它——一旦您這樣做，您就可以合併根據 LGPLv3 發布的程式碼。

5：在這種情況下合併程式碼時，您必須遵守 LGPLv2.1 的條款。您不能利用 LGPL 後續版本中的條款。

6：如果您這樣做，只要專案包含根據僅限 LGPLv2.1 條款發布的程式碼，您將無法將專案的授權條款升級到 LGPLv3 或後續版本。

7：LGPLv2.1 授權您根據 GPL 的任何版本（自 GPLv2 以來）重新授權程式碼。如果在此情況下，您可以將 LGPL 授權的程式碼切換為使用適當版本的 GPL（如表中所述），則可以進行此組合。

8：LGPLv3 是 GPLv3 加上您可以在這種情況下忽略的額外許可。

9：由於 GPLv2 不允許與 LGPLv3 組合，因此在這種情況下，您必須根據 GPLv3 的條款傳達專案，因為它將允許該組合。