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

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

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

2、**對於 GNU 許可證的一般了解**

2.1 為什麼 GPL 允許用戶發布其修改版本？

自由軟體的一個關鍵特點是用戶可以自由合作。絕對有必要允許希望彼此幫助的用戶與其他用戶分享他們對錯誤的修復和改進。

有些人提出了 GPL 的替代方案，需要原作者批准修改版本。只要原作者持續進行維護，這種做法在實踐中可能會不錯，但是如果作者停止維護（或多或少會）去做別的事情，或並不打算去滿足所有用戶的需求，這種替代方案就會失敗。除了實踐上的問題之外，該方案也不允許用戶之間互相幫助。

有時候對修改版本的控制，是為了防止用戶製作的各種版本之間造成混淆。根據我們的經驗，這種混亂不是一個大問題。在 GNU 項目之外出現了許多版本的 Emacs，但用戶仍可以將它們區分開。GPL 要求版本創造者將他/她的名字標註其上，以區別於其他版本，並保護其他維護者的聲譽。

2.2 GPL 是否要求將修改版本的源代碼公開發布？

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

但是，如果您以某種方式向公眾發布修改後的版本，依據 GPL 許可證，GPL 要求您保證程序的用戶可以獲得修改後源代碼。

因此，GPL 給你以某些特定方式發布修改後的程序的授權，而不是以其他方式發布；但是，是否發布修改版本的決定取決於您。

2.3 我可以在同一台電腦上安裝一個遵循 GPL 許可證的程序和一個不相關的非自由程序嗎？

可以。

2.4 如果我知道某些人有一個遵循 GPL 許可證的程序的副本，我可以要求他們給我一個副本嗎？

不可以，GPL 給人們製作和再分發程序副本的授權，倘若有人選擇這樣做的話。那個人也有權選擇不去再分發該程序。

2.5 GPL v2 中的「 書面文件 （ written offer ） 對任何第三方有效」是什麼意思？ 這是否意味著世界上每個人都可以獲得任何遵循 GPL 許可證的程序的源代碼？

如果您選擇通過書面文件提供源代碼，那麼任何向您索求源代碼的人都有權收到。

如果您對不附帶源代碼的二進位文件進行商業分發，GPL 要求您必須提供一份書面文件，表明將稍後分發源代碼。當用戶非商業性地再分發他們從您那裡獲取的二進位文件時，他們必須傳遞這份書面文件的副本。這意味著不能直接從您那裡獲取二進位文件的人，仍然可以收到源代碼副本以及該書面文件。

我們要求書面文件對任何第三方有效的原因是，以這種方式間接收到二進位代碼的人可以從您那裡訂購源代碼。

2.6 GPL v2 中規定，發布後的修改版本必須「授予…所有第三方許可」。這些第三方是誰？

第 2 節中規定，依據 GPL，您分發的修改版本必須授權給所有第三方。 「所有第三方」當然是指所有人，但這並不要求您為他們做任何事情。這僅僅意味著他們依據 GPL 從您那裡獲得了您的修改版本的許可。

2.7 GPL 允許我出售程序的副本以獲利嗎？

是的，GPL 允許每個人這樣做。銷售副本的權利是自由軟體定義的一部分。除了一種特殊情況之外，對您可以收取什麼樣的價格是沒有限制的。（這種例外情況是：二進位版本必須附有表明將提供源代碼的書面文件。）

2.8 GPL 允許我從我的分髮網站收取下載程序的費用嗎？

允許。您可以對您分發程序副本收取任何您想收取的費用。如果您通過下載分發二進位文件，則必須提供「等同的訪問許可權」來讓人們下載源代碼，因此，下載源代碼的費用可能不會超過下載二進位文件的費用。

2.9 GPL 允許我要求任何接收軟體的人必須向我支付費用和/或通知我嗎？

不允許。實際上，這樣的要求會使程序變成非自由軟體。如果人們在獲得程序副本時必須支付費用，或者他們必須特別通知任何人，那麼這個程序就不是自由軟體。請參閱自由軟體的定義。

GPL 是自由軟體許可證，因此允許人們使用甚至再分發軟體，而不需要向任何人支付費用。

您可以向用戶收取費用，以獲取您的副本。當他們從別人那裡獲得副本時，您不能要求人們向您支付費用。

2.10 如果我收費分發遵循 GPL 的軟體，我是否還需要向公眾免費提供？

不需要。不過，如果有人向您支付費用並獲得副本，GPL 給予他們免費或收費向公眾發布的自由。例如，有人可以向您支付費用，然後把他的副本放在一個網站上，讓公眾去獲取。

2.11 GPL 允許我根據保密協議分發副本嗎？

不允許。GPL 規定，任何從您那裡獲取副本的人都有權再分發已修改或未修改的副本。您不得在任何更嚴格的基礎上分發作品。

如果有人要求您簽署保密協議（NDA），以獲取來自 FSF 的遵循 GPL 的軟體，請立即通知我們 license-violation@fsf.org。

如果違規行為涉及其他版權所有者的遵循 GPL 的代碼，請通知該版權所有者，就像您對其他任何類型的 GPL 違規行為所做的工作一樣。

2.12 GPL 允許我根據保密協議分發程序的修改版或測試版嗎？

不可以。GPL 規定，您的修改版本必須具備 GPL 中規定的所有自由。因此，從您那裡獲取您的版本副本的任何人都有權再分發該版本的副本（已修改或未修改）。您不得在更嚴格的基礎上分發該作品的任何版本。

2.13 GPL 是否允許我根據保密協議開發程序的修改版本？

可以。例如，您可以接受一份合同來開發修改版本，並同意不得發布您的修改版本，直到客戶同意才可以發布。這是允許的，因為這種情況下不處於 GPL 協議之下的代碼是依據 NDA 分發的。

您還可以依據 GPL 將您的修改版本發布給客戶，但須同意不將其發布給其他任何人，除非客戶同意。也同樣在這種情況下，不處於 GPL 協議之下的代碼是以保密協議或任何其他限制條款分發的。

GPL 將給予客戶再分發您的版本的權利。在這種情況下，客戶可能會選擇不行使這項權利，但他確實擁有這項權利。

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

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

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

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

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

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

2.16 我是否需要將我對遵循 GPL 的程序所做的修改聲明版權？

您不需要對您的修改聲明版權。不過，在大多數國家/地區，默認情況下會自動獲得版權，因此，如果您不希望修改受到版許可權制，您需要將修改明顯地放置於公有領域。

無論您是否對您的修改聲明版權，依據 GPL，您都必須將修改版本作為整體發布（參見：2.2 GPL 是否要求將修改版本的源代碼公開發布？）。

2.17 GPL 對於將某些代碼翻譯成不同的編程語言是如何規定的？

根據著作權法，翻譯工作被認為是一種修改。因此，GPL 對修改版本的規定也適用於翻譯版本。

2.18 如果一個程序將公有領域代碼與遵循 GPL 的代碼相結合，我可以取出公有領域的部分，並作為公有領域代碼來使用嗎？

您可以這樣做，如果您能弄清楚哪個部分是公有領域的部分，並將其與其他部分區分開。如果代碼曾經由其開發人員放置在公有領域，那麼它就是公有領域代碼，無論它現在究竟在哪裡。

2.19 我想要因我的作品獲得聲譽。我想讓人們知道我寫了什麼，如果我使用 GPL，我還能獲得聲譽嗎？

您一定能獲得這份作品的聲譽。遵循 GPL 發布的程序的一部分是以您自己名義撰寫的版權聲明（假設您是版權所有者）。GPL 要求所有副本攜帶恰當的版權聲明。

2.20 GPL 允許我添加條款，要求在使用遵循 GPL 的軟體或其輸出物的研究論文中包含引用或致謝嗎？

不可以，根據 GPL 的規定，這是不允許的。雖然我們認識到適當的引用是學術出版物的重要組成部分，但引用不能作為對 GPL 的附加要求。對使用 GPL 軟體的研究論文要求包含引用，超出了 GPL v3 第 7（b）條中可接受的附加要求，因此將被視為對 GPL 第 7 節的額外限制。而且版權法也不允許您在軟體的輸出物中設置這樣的要求，無論該軟體是依據 GPL 還是其他許可證的條款獲得許可。

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

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

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

2.22 兩個許可證「兼容」是指什麼？

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

對於一些許可證，組合的方式可能會影響它們是否兼容，例如，它們可能允許將兩個模塊鏈接在一起，但不允許將其代碼合併到一個模塊中。

如果您只想在同一個系統中安裝兩個獨立的程序，那麼它們的許可證並不是必須兼容的，因為它們沒有組合成更大的作品。

2.23 許可證與 GPL 兼容是什麼意思？

這意味著其他許可證和 GNU GPL 兼容；在一個更大的程序中，您可以將根據其他許可證發布的代碼與根據 GNU GPL 發布的代碼進行組合。

所有 GNU GPL 版本都允許進行這種組合；它們還允許分發這些組合，只要該組合在相同的 GNU GPL 版本下發布。其他許可證如果允許這樣做，則其與 GPL 兼容。

與 GPL v2 相比，GPL v3 與更多的許可證兼容：它允許您與具有特定類型附加要求（GPL v3 本身不包含）的代碼進行組合。GPL v3 第 7 節中有關於此問題的更多信息，包括了允許的附加要求的列表。

2.24 為什麼原始的 BSD 許可證與 GPL 不兼容？

因為它規定了 GPL 不包含的具體要求，即對程序廣告的要求。GPL v2 第 6 節規定：

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

GPL v3 在第 10 節中提到類似的內容。廣告條款正好提供了這樣一個限制，因此與 GPL 不兼容。

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

2.25 「 聚合 （ aggregate ） 」與其他類型的「修改版本」有什麼區別？

「聚合」由多個單獨的程序組成，分布在同一個 CD-ROM或其他媒介中。GPL 允許您創建和分發聚合，即使其他軟體的許可證不是自由許可證或與 GPL 不兼容。唯一的條件是，發布「聚合」所使用的許可證不能禁止用戶去行使「聚合」中每個程序對應的許可證所賦予用戶的權利。

兩個單獨的程序還是一個程序有兩個部分，區分的界限在哪裡？這是一個法律問題，最終由法官決定。我們認為，適當的判斷標準取決於通信機制（exec、管道、rpc、共享地址空間內的函數調用等）和通信的語義（哪些信息被互換）。

如果模塊們被包含在相同的可執行文件中，則它們肯定是被組合在一個程序中。如果模塊們被設計為在共享地址空間中鏈接在一起運行，那麼幾乎肯定意味著它們組合成為一個程序。

相比之下，管道、套接字和命令行參數是通常在兩個獨立程序之間使用的通信機制。所以當它們用於通信時，模塊們通常是單獨的程序。但是，如果通信的語義足夠親密，交換複雜的內部數據結構，那麼也可以視為這兩個部分合併成了一個更大的程序。

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

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

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

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

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

2.27 如果我使用遵循 GNU GPL 的軟體，那麼允許我將原始代碼修改為新程序，然後在商業上分發和銷售新程序嗎？

您被允許在商業上出售修改程序的副本，但僅限於在 GNU GPL 的條款之下這麼做。因此，例如，您必須依照 GPL 所述，使得程序用戶可獲取源代碼，並且，用戶也依照 GPL 所述，被允許再分發和修改程序。

這些要求是將遵循 GPL 的代碼包含在您自己的程序中的條件。

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

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

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

2.29 我想依據 GPL 授權我的代碼，但我也想明確指出，它不能用于軍事和/或商業用途。我可以這樣做嗎？

不可以，因為這兩個目標相互矛盾。GNU GPL 被專門設計為防止添加進一步的限制。GPL v3 在第 7 節允許非常有限的一組附加限制，但是用戶可以刪除任何其他添加的限制。

2.30 我可以依據 GPL 來對硬體進行許可嗎？

任何可以受版權保護的 材料 （ material ） 都可以依據GPL進行許可。GPL v3 也可以用於受其他類似版權法的法律保護的材料，如半導體掩模。因此，作為一個例子，您可以依據 GPL 發布物理對象的圖紙或電路。

在許多情況下，版權不涵蓋依照圖紙製作的物理硬體。在這種情況下，無論您使用什麼許可證，您對圖紙的許可都不能對製造或銷售物理硬體施加任何控制。當版權不涵蓋利用 IC 掩膜等進行硬體製作時，GPL 能以有效的方式處理這種情況。

2.31 將遵循 GPL 的二進位文件 預鏈接 （ prelinking ） 到系統上的各種庫，以優化其性能，將被視為修改嗎？

不。 預鏈接 （ prelinking ） 是編譯過程的一部分；與編譯過程所涉及的其他各個方面相比，預鏈接沒有引入更多的許可證要求。如果您被允許將程序鏈接到各種庫，那麼也可以預鏈接到各種庫。如果您分發預鏈接後的目標碼，則需要遵循第 6 節的條款。

2.32 LGPL 如何與 Java 配合使用？

詳情請參閱這篇文章。LGPL 如同被設計、被預想、被期待的那樣去工作。

2.33 為什麼你們在 GPL v3 中發明新的術語「 傳播 （ propagate ） 」和「 傳遞 （ convey ） 」？

（譯者註：convey 這個辭彙在一個 GPL 譯本中被翻譯為「轉發」，此處，我們認為「轉發」一詞在計算機領域存在一定的歧義，因此，採用「傳遞」的翻譯。）

GPL v2 中使用的「分發」一詞來自美國版權法。多年來，我們了解到，一些司法管轄區在自己的版權法中使用了同一個詞，但卻給出了不同的含義。我們發明了這些新術語，無論在何處對許可證進行解釋，都使我們的意圖儘可能清楚。這些新術語沒有使用在世界上的任何版權法中，我們直接在許可證中提供了它們的定義。

2.34 在GPL v3中的「 傳遞 （ convey ） 」與GPL v2中的「 分發 （ distribute ） 」意思一樣嗎？

是的，差不多是一個意思。在執行 GPL v2 的過程中，我們了解到一些司法管轄區在自己的版權法中使用了「分發」這個詞，但給出了不同的含義。我們發明了一個新的術語，以使我們的意圖清晰，避免這些差異可能引起的任何問題。

2.35 如果我只複製遵循 GPL 的程序並運行它們，而不分發或傳遞給其他人，許可證對我施加什麼要求？

沒有要求。GPL 不對此活動附加任何條件。

2.36 GPL v3將「向公眾提供」作為 傳播 （ propagate ） 的一個例子。這是什麼意思？ 是提供一種可獲取的傳遞形式嗎？

「向公眾提供」的一個例子是將該軟體放在公共網頁或FTP伺服器上。在您這樣做之後，在任何人從您那裡真正獲取軟體之前，可能會需要一段時間，但是由於這種情況可能會立即發生，您也需要能夠立即履行 GPL 的義務。因此，我們將「 傳遞 （ convey ） 」定義為包括這一活動。

2.37 鑒於分發和向公眾提供作為傳播形式，同樣也構成了 GPL v3 中的「 傳遞 （ conveying ） 」，那麼有哪些傳播的例子不構成傳遞嗎？

為自己製作軟體的副本是不構成「傳遞」的主要傳播形式。您可以依此在多台計算機上安裝軟體，或進行備份。

2.38 GPL v3 如何讓 BitTorrent 分發變得更容易？

因為 GPL v2 是在軟體的點對點分發普及之前編寫的，所以當您利用這種方式分享代碼時，很難滿足 GPL v2 的要求。在 BitTorrent 上分發 GPL v2 目標代碼時，確保您合規的最佳方法是將所有相應的源代碼包含在相同的 種子文件 （ Torrent ） 中，但這種方式代價高昂。

GPL v3 以兩種方式解決了這個問題。首先，作為該過程的一部分，下載此種子文件並將數據發送給其他人的人不需要做任何事情。因為第 9 節規定：「受保護作品的輔助傳播如果僅僅是使用點對點傳輸來接收副本，不需要接受[本許可證]。」

第二，通過告知接收人在公共網路伺服器上哪裡可獲取，GPL v3 的第 6（e）節旨在給予分發者（最初製作種子文件的人）一種清晰、直觀的方式來提供源代碼。這樣可以確保每個想要獲取源代碼的人都可以如此獲取，而且分發者幾乎不用擔心。

2.39 什麼是 TiVo化 （ tivoization ） ？ GPL v3 對此如何防止？

一些設備使用可升級的自由軟體，但被設計為用戶不能修改該軟體。有很多不同的方式可以做到這一點；例如，有時硬體校驗所安裝的軟體，如果與預期簽名不匹配，則關閉軟體。製造商通過提供源代碼來遵循GPL v2，但是您仍然無法自由修改您使用的軟體。我們稱這種做法為 TiVo 化 （ tivoization ） 。

當人們分發包含遵循 GPL v3 軟體的「 用戶產品 （ User Products ） 」時，第 6 節要求他們為您提供修改該軟體所需的信息。「用戶產品」是該許可證特別定義的術語；「用戶產品」的示例包括攜帶型音樂播放器、數字錄像機和家庭安全系統。

2.40 GPL v3 是否禁止 DRM？

不禁止，您可以使用遵循 GPL v3 發布的代碼來開發您喜歡的任何類型的 DRM 技術。不過，如果您這樣做，第 3 節規定，系統不會被視為一種有效的技術「保護」措施，這意味著如果有人破壞了 DRM，他也可以自由分發他的軟體，不受《美國數字千禧版權法》（DMCA）和類似法律的限制。

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

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

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

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

2.42 GPL v3 是否包含「專利報復條款」？

實際上，是的。第 10 節禁止傳遞該軟體的人向其他被許可人發起專利訴訟。如果有人這樣做，第 8 節解釋他們將如何喪失許可證權益以及與之伴隨的所有專利許可。

2.43 在 GPL v3 和 AGPL v3中，當說到「儘管有本許可證的其他規定」時，是什麼意思？

這僅僅意味著以下條款勝過許可證中可能與之衝突的其他任何內容。例如，如果沒有該文本，有些人可能聲稱，您不能將遵循 GPL v3 的代碼與遵循 AGPL v3 的代碼結合在一起，因為 AGPL 的附加要求將被歸類為 GPL v3 第 7 節下的「進一步限制」。該文本明確表示我們的預期解釋是正確的，您可以進行組合。

該文本僅解決許可證不同條款之間的衝突。當兩個條件之間沒有衝突的時候，您必須同時滿足它們。這些段落不允許您輕率地忽略許可證的其餘部分，它們只是強調了一些非常有限的例外。

2.44 在 AGPL v3 中，怎麼才算是「通過計算機網路遠程與[軟體]進行交互」？

如果程序被明確設計為接受用戶請求並通過網路發送響應，則它符合這些標準。屬於此類程序的常見示例包括網路和郵件伺服器、互動式網路應用程序和在線遊戲的伺服器。

如果程序沒有被明確設計為通過網路與用戶進行交互，而是恰好在這樣做的環境中運行，那麼它不屬於此類。例如，僅僅因為用戶通過 SSH 或遠程 X 會話來運行的應用程序不需要提供源代碼。

2.45 GPL v3 中「 您 （ you ） 」的概念如何與 Apache License 2.0 中「 法律實體 （ Legal Entity ） 」的定義相比較？

它們是完全相同的。Apache License 2.0 中「法律實體」的定義在各種法律協議中是非常標準的，因此，如果法院在缺乏明確定義的情況下沒有以同樣的方式解釋該術語，將會令人非常驚訝。我們完全期待他們在看 GPL v3 時也會如此，並考慮到誰有資格作為被許可人。

2.46 在 GPL v3 中，「 該程序 （ the Program ） 」是指什麼？ 是每個依據 GPL v3 發布的程序？

術語「該程序」是指依據 GPL v3 進行許可的特定作品，由特定被許可人從上游許可人或分發者那裡接收。「該程序」是您在 GPL v3 許可的指定情境下接受到的特定軟體作品。

「該程序」並不意味著「依據 GPL v3 進行許可的所有作品」；由於一些原因，這種解釋沒有任何意義。針對那些想要了解更多的人，我們已經發表了對「該程序」一詞的分析。

2.47 如果某些網路客戶端軟體依據 AGPL v3 發布，是否必須能夠向與之交互的伺服器提供源代碼？

AGPL v3 需要該程序向「所有通過計算機網路進行遠程交互的用戶」提供源代碼。至於您將程序稱為「客戶端」還是「伺服器」，那無關緊要。您需要詢問的問題是，是否存在合理的期望讓一個人通過網路遠程與該程序交互。

2.48 對於一個運行在代理伺服器上的依據 AGPL 進行許可的軟體來說，如何向與該軟體交互的用戶提供源代碼書面文件？

對於代理伺服器上的軟體，您可以通過向此類代理的用戶傳遞消息的常規方法來提供源代碼書面文件。例如，Web 代理可以使用登錄頁。當用戶最初開始使用代理時，您可以將他們引導到包含源代碼書面文件以及您選擇提供的任何其他信息的頁面。

AGPL 規定，您必須向「所有用戶」提供書面文件。如果您知道某個用戶已經被展示過書面文件，對於當前版本的軟體，您不必再重複向該用戶提供。

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