跳至內容

GNU通用公眾授權條款

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
「GPL」重新導向至此。關於一場電子競技聯賽，請見「GPL超級聯賽」。
GNU通用公眾授權條款
GNU GPLv3 Logo
作者自由軟體基金會
版本第3版
釋出者自由軟體基金會
釋出日期1989年2月25日，​35年前​（1989-02-25）
DFSG相容是[1]
自由軟體是[2]
OSI認證是[3]
Copyleft是[2][4]
與不同授權條款代碼連結僅可與GNU AGPLv3代碼相連結[5]
網站www.gnu.org/licenses/gpl.html 編輯維基數據鏈結

GNU通用公眾授權條款（英語：GNU General Public License，縮寫GNU GPL 或 GPL），是被廣泛使用的自由軟體授權條款，給予了終端使用者運行、學習、共享和修改軟體的自由。[6]授權條款最初由自由軟體基金會的理察·斯托曼為GNU專案所撰寫，並授予電腦程式的使用者自由軟體定義（The Free Software Definition）的權利。[7]GPL是一個Copyleft授權條款，這意味著只要專案的某個部分（如動態連結庫）以GPL發佈，則整個專案以及衍生作品只能以相同的許可條款分發[8]。這與寬鬆自由軟體授權條款有所區別 ，如BSD授權條款和MIT授權條款就是其中被廣泛使用的例子。GPL是第一個普遍使用的Copyleft授權條款。

歷史上，GPL授權條款系列一直是自由和開源軟體領域最受歡迎的軟體許可之一。[6][9][10][11][11][11][12][13]根據GPL許可的優異自由軟體程式的例子有Linux核心和GNU編譯器集合（GCC）。大衛·A·惠勒（英語：David A. Wheeler）認為，GPL提供的Copyleft對於基於Linux的系統的成功至關重要，給予向核心貢獻的程式設計師保證他們的工作將有益於整個世界並保持自由，而不至於被不提供回饋給社群的無良軟體公司所剝削。[14]

2007年，發布了第三版授權條款（GNU GPLv3），以解決在長期使用期間發現的第二版（GNU GPLv2）所發生的一些困擾。為了使授權條款保持最新狀態，GPL授權條款包含一個可選的「並延伸到未來版本」條款，允許使用者在FSF更新的原始條款或新版本之間進行選擇。有些開發人員在軟體授權使用時，選擇省略它；例如，Linux核心已經在GPLv2下獲得許可，就不需包括「並延伸到未來版本」的聲明。[15][16]

GPL授予程式接受人以下權利，或稱「自由」，或稱「copyleft」：

  • 基於任何目的，按你的意願執行軟體的自由（自由之零）。
  • 學習軟體如何工作的自由，按你的意願修改軟體以符合你的計算的自由（自由之一）。可訪問原始碼是此項自由的先決條件。
  • 分發軟體副本的自由，因此你可以幫助你的好友（自由之二）。
  • 將你修改過的軟體版本再分發給其他人的自由（自由之三）。這樣可以讓整個社群有機會共享你對軟體的改動。可訪問原始碼是此項自由的先決條件。[17]

相反地，隨著作權所有軟體的終端使用者授權合約幾乎從不授予使用者任何權利（除了使用的權利），甚至可能限制一些法律允許的行為，比如還原工程。

GPL與其他一些更「許可的」自由軟體授權條款（比如BSD授權條款）相比，主要區別就在於GPL尋求確保上述自由能在複製軟體及衍生作品中得到保障。它透過一種由斯托曼發明的叫Copyleft的法律機制實現，即要求GPL程式的衍生作品也要在GPL之下。相反，BSD式的授權條款並不禁止改作作品變成專有軟體。

GPL是自由軟體和開源軟體的最流行授權條款[18]。到2004年4月，GPL已占Freshmeat（英語：Freshmeat）上所列的自由軟體的約75%，SourceForge的約68%。類似的，2001年一項關於Red Hat Linux 7.1的調查顯示一般的代碼都以GPL發布。著名的GPL自由軟體包括EMACS，Linux核心（並非所有Linux發行版的核心都是開源的）和GCC。

歷史

GPL由理察·斯托曼於1989年編寫，提供給列入GNU專案的一些軟體程式所使用。原始的GPL基於GNU Emacs（1985），[19]GNU Debugger和GNU C編譯器的早期版本中使用的類似授權條款的統一。[20]這些授權條款包含與現代GPL類似的規定，但具體針對每個程式，使其不相容，儘管是相同的授權條款。[21]Stallman的目標是提供一個可用於任何專案的授權證，從而使許多專案得以共享代碼。GPL版本1就這樣，在1989年1月誕生。

到1990年時，某些因素使得程式庫（Library），應該要有比GPL更寬鬆的授權許可的需求。所以當GPL版本2在1991年6月發布，另一授權條款——程式庫通用授權條款（Library General Public License，簡稱 LGPL）也隨之誕生，並記作「版本2」以示對GPL的補充。版本號在LGPL版本2.1發布時不再相同，而LGPL也被重新命名為GNU較寬鬆公共許可證以體現GNU的哲學觀。

授權條款的第二個版本，版本2，在1991年發布。在接下來的15年中，自由軟體社群的成員很關心GPLv2授權條款中的問題，可能會讓某些人鑽漏洞而違反授權條款，而違背了原先GPL許可授權軟體的原意。[22]這些問題包括Tivo化（英語：Tivoization）[23]（來自硬體的軟體限制，意指將GPL授權軟體安裝在硬體上，又拒絕運行更動相關軟體的修改版本），類似與Affero通用公眾授權條款類似的相容性問題，以及微軟和自由開源軟體，其中一些被認為試圖將專利申請用作於對付自由軟體社群的武器。

第3版旨在解決這些問題，並於2007年6月29日正式發布。[24]

用語

根據創用CC官方網站，GNU General Public License 的台灣法律用語翻法為「GNU通用公共授權條款」[25]，香港法律用語翻法亦為如此[26]。

GPLv1

1989年2月25日發布的GNU GPL 版本1阻止了軟體經銷商限制自由軟體定義的兩個主要方式。第一個問題是經銷商可能僅發布二進位檔案 - 可執行，但不能由人類讀取或修改。為了防止這種情況，GPLv1表示，任何分發二進位代碼的供應商還必須按照相同的許可條款（授權條款的第3a和3b節）提供可讀的原始碼。

第二個問題是經銷商可能會增加授權條款的限制，也可能會將軟體與其他具有其他分發限制的軟體相結合。兩套限制的聯合將適用於組合工作，從而增加不可接受的限制。為了防止這種情況，GPLv1表示，修改後的版本作為一個整體，必須按照GPLv1（授權條款第2b和4節）的條款分發。因此，根據GPLv1條款分發的軟體可以以更寬鬆的條款與軟體相結合，因為這不會改變整體可以分發的條款。然而，根據GPLv1分發的軟體不能與在更嚴格的授權條款下分發的軟體相結合，因為這與根據GPLv1的條款可以分發的要求相衝突。

GPLv2

根據理察·斯托曼的說法，GPLv2的主要變化是「自由或死亡」（Liberty or Death）條款[21]。就如字面上所說，「被許可人只有在滿足所有授權條款的義務下」才可以分發包含GPL授權的軟體，儘管他們可能擁有任何其他法律義務。換句話說，就算有相互矛盾的義務，授權條款的義務也可能不被切斷。該條款旨在阻止任何一方使用專利侵權（英語：Patent infringement）索賠或其他訴訟來損害使用者在授權條款下的自由。這章中的意思是，為了在一定程度上保障和尊重其它一些人的自由和權益，無論任何人要發布源於GPL的軟體的時候，同時也須遵守強制的條款分享原始碼，否則他將根本無權發布該軟體。[註 1]

到1990年，越來越明顯的是，對於C函式庫來說，本質上已經跟受專利保護的軟體函式庫的功能表現相當，有一個限制較少授權條款對於自由軟體發展的策略上來說更為實用；因此，當GPL的版本2（GPLv2）在1991年6月發佈時，第二類別的授權條款：函式庫通用公眾授權條款（英語：Library General Public License），也同時被引入，並從第二版編號開始，表明兩者是互補的。版本號在1999年發行，當時LGPL的版本2.1被發布，更名為GNU寬鬆通用公眾授權條款（英語：Lesser General Public License），以反映其在哲學中的地位。

最常見的是「GPLv2並延伸到未來版本」的聲明，讓授權條款的使用者了解，得以允許升級到GPLv3。

GPLv3

GPLv3 logo
理察·斯托曼起草了第一份GNU GPLv3草案，在美國麻州劍橋的麻省理工學院。在他右手邊站的是哥倫比亞法律教授伊本·莫格林，軟體自由法律中心主席

到2005年，GPL版本3開始由斯托曼起草，由伊本·莫格林和軟體自由法律中心（Software Freedom Law Center）提供法律咨詢[27]。2005年底，自由軟體基金會 （FSF）宣布了GPL（GPLv3）第3版的工作。2006年1月16日，公佈了GPLv3的第一個「討論稿」，公眾諮詢開始。公眾諮詢原計劃為九至十五個月，但最終延長至十八個月，其中出版四份草案。2007年6月29日，官方正式版GPLv3於由FSF發布。[28]

之後，理察·斯托曼在2006年2月25日自由及開源軟體開發者歐洲會議的演講時談到最重要的四件事：

  • 解決軟體專利問題；
  • 自由軟體授權條款與其它商用許可的相容性問題；
  • 原始碼分割與組成的定義；
  • 解決數位版權管理的問題，意即反軟體修改的硬體限制。

還有一些其他的更改涉及國際化，如何處理授權條款違規，以及著作權所有者如何授予額外權限。[27][29]它還增加了一項規定，「剝離」（strips）其法定價值的數位版權管理（Digital Rights Management，縮寫DRM），所以人們可以合理的當在法院被視為侵犯DRM時，去破解運行GPL軟體的任何東西，而不會違反DMCA等法律。[30]

公共諮詢過程由自由軟體基金會在軟體自由法律中心、歐洲自由軟體基金會（英語：Free Software Foundation Europe）[31]和其他自由軟體組織的協助下進行協調。透過FSF [1] （頁面存檔備份，存於網際網路檔案館）網站從公眾收集評論[32]。該門戶網站運行名為 stet（英語：stet (software)）的專用軟體。在公眾諮詢過程中，提交了第一稿的962條意見[33]。最後，共提交了2636條意見[34][35][36]。

第三稿於2007年3月28日發布[37]。該草案包括旨在防止與專利相關協定（如有爭議的Microsoft-Novell專利協定）的語言 ，並將反傾銷條款限於「使用者」或「消費品」。它還明確刪除了「地理限制」一節，確認公開諮詢開始時就提到可能會刪除的這一部分。

最後的第四個討論草案[38]於2007年5月31日發布。它引入了Apache授權條款版本2.0相容性（以前的版本不相容），澄清了外部承包商的作用，並提出了一個例外，以避免充滿爭議的Microsoft-Novell專利協定再度發生，在第11節第6段中說：

這旨在使未來像這樣的交易無效。該授權條款還意味著Microsoft將其授予Novell客戶的專利授權條款擴展到使用GPLv3軟體的所有使用者，使用GPLv3軟體；除非當Microsoft合法地是GPLv3軟體的「傳送者」時，才有可能[39][40]。

此外，GPLv3的早期草案讓許可方添加了一個Affero類的需求，將會填補GPL中的ASP漏洞[41][42]。由於擔憂該附加要求的代碼檢查所需要的額外行政費用，決定將GPL和Affero授權條款分開[43]。

值得留意的是Linux核心的一些高調的開發人員 ，例如林納斯·托瓦茲、葛雷格·克羅哈曼和安德魯·莫頓，向大眾媒體發表了評論，並就討論草案1和2的部分內容作了公開聲明[44]。核心開發人員提及關於DRM/Tivoization（英語：Tivoization）、專利和「附加限制」的GPLv3草案條款，並警告會產生「開源宇宙」（Open Source Universe）的巴爾幹半島式分裂[44][45]。林納斯·托瓦茲決定不採用GPLv3作為Linux核心，仍然使用GPLv2授權[15]，甚至在幾年後重申了他的批評[46][47]。此事曾引起理察·斯托曼的不滿。

GPLv3提高了與許多開放原始碼軟體授權條款（如Apache授權條款版本2.0）和GNU Affero通用公眾授權條款（GPLv2無法組合）的相容性[48]。但是，如果所使用的GPLv2授權條款具有可選的「或更高版本」子句，並且軟體升級到GPLv3，GPLv3軟體只能與GPLv2軟體組合並共享代碼。雖然FSF認為「GPLv2並延伸到未來版本」條款是許可GPLv2軟體的最常見形式[49]，諸如Toybox（英語：Toybox）開發商Rob Landley將其描述為「救生艇條款」（lifeboat clause）[50][51]。使用可選「或更高版本」條款許可的軟體專案包括GNU專案，而沒有該子句的最明顯的案例是Linux核心[52]。

授權條款文字的最終版本於2007年6月29日由自由軟體基金會正式發布[28]。

條款和條件

GPL的條款和條件必須提供給任何接受GPL應用的作品的副本（「被許可人」）的人員。任何遵守條款和條件的被授證人員都有權修改作品，以及複製和重新分發作品或任何衍生版本。被許可人被允許為此服務收取費用，或無償。後一點將GPL與禁止商業再分發的軟體許可區分開來。FSF認為，自由軟體不應該限制商業用途，[53]GPL明確規定GPL作品可能以任何價格出售。

GPL還規定，經銷商不得對GPL授予的權利施加「進一步限制」。禁止根據不披露協定或合同分發軟體等活動。

授權條款版本2的第四部分和版本3的第七部分要求，作為預編譯二進位檔案分發的程式應附有原始碼的副本，透過與前一版本相同的機制分發原始碼的書面報價編譯的二進位檔案或書面報價，以獲取使用者在GPL下接收預編譯二進位檔案時獲得的原始碼。版本2的第二部分和版本3的第五部分還要求「所有收件人本程式附帶的授權條款副本」。授權條款的版本3允許以其他方式提供原始碼來實現第七部分。這些包括從相鄰網路伺服器下載原始碼或透過對等傳輸，只要編譯代碼是可用的，並且在哪裡可以找到原始碼的「清晰方向」。

除非作者明確賦予 FSF 著作權（除了作為GNU專案一部分的程式很少發生），否則FSF對GPL發布的作品不具有著作權。只有個人著作權持有人有權在發生授權條款時才起訴。

使用許可軟體

GPL下的軟體可以用於所有目的，包括商業目的，甚至作為建立專有軟體的工具，例如使用GPL授權的編譯器時[54]。分發GPL許可作品（如軟體）的使用者或公司可能會收取副本費用或無償提供費用。這將GPL與共享軟體授權條款區分開來，允許複製用於個人使用，但禁止商業發佈，或著作權法禁止複製的專有許可。FSF認為自由軟體不應該限制商業使用和發佈（包括再發佈）[53]。GPL明確規定，GPL工作可能以任何價格出售。

在純私人（或內部）使用 - 沒有銷售和沒有發行 - 軟體代碼可能被修改和零件重複使用，而不需要發布原始碼。對於銷售或分銷，整個原始碼需要提供給終端使用者，包括任何代碼更改和添加 - 在這種情況下，應用copyleft來確保終端使用者保留上面定義的自由。[55]

然而，作為GPL許可作業系統（如Linux）下的應用程式運行的軟體不需要根據GPL進行許可或者以原始碼可用性分發 - 許可只依賴於使用的庫和軟體組件，而不是依賴於底層平台[56]。例如，如果一個程式僅由自己的原始客製化軟體組成（software component），或者與其他軟體組件的原始碼組合在一起[註 2]，則自己的客製化軟體組件不需要根據GPL授權，不需要使其代碼可用；即使所使用的底層作業系統是根據GPL授權的，運行在其上的應用程式也不被視為衍生作品。[56]只有在程式中使用了GPLed部件（程式已經分發）的情況下，程式的所有其他原始碼才能在相同的許可條款下提供。GNU較寬鬆公眾授權條款（LGPL）被建立為具有比GPL更弱的Copyleft，因為它不需要在相同的許可條款下提供自己客製化的原始碼（不同於LGPLed部分）。

Copyleft

主條目：Copyleft

GPL授權版本的修改後作品的發行權不是無條件的。當有人分發GPL的作品又加上自己的修改時，分發整個作品的要求不能大於GPL中的要求。這個要求被稱為Copyleft。它透過軟體程式使用著作權獲得法律權力。由於GPL的作品受著作權保護，被許可人無權重新分發，即使是以修改形式（除合理使用 ）外，除了許可條款外， 如果希望行使通常受著作權法限制的權利，例如重新分配，只需遵守GPL的條款。相反，如果在不遵守GPL條款（例如保留原始碼秘密）的情況下分發作品的副本，則原始作者可以根據著作權法提起訴訟。因此，「Copyleft使用著作權法來完成」與常見法律的設定目的相反，不是施加限制，而是「賦予其他人權利，以確保權利不能隨之被剝奪的方式。」如果在Copyleft聲明中找到任何法律缺陷，它也可以確保不給予無限的重新分發權限。[來源請求]

許多GPL程式的經銷商將原始碼與執行檔捆綁在一起。滿足Copyleft的替代方法是提供書面報價，以便在物理介質（如CD）上提供原始碼。實際上，許多GPL的程式透過Internet進行分發，原始碼透過FTP 或 HTTP提供。對於網際網路分發，這符合授權條款。只有當一個人試圖重新分發程式時，Copyleft才適用。只要不將修改後的軟體分發給任何人，開發人員可以製作私有修改版本，無需洩露修改。請注意，Copyleft僅適用於軟體，而不適用於其輸出（除非該輸出本身是程式的衍生作品[註 3]）。

例如，運行GPL內容管理系統（CMS）修改版的衍生產品之公共門戶網站不需將其更動分發給底層軟體，因為其輸出不是衍生產品。

有人辯論，如果以程式碼混淆形式發布原始碼是否違反GPL，例如在作者不太願意提供原始碼的情況下。普遍認為雖然這是不道德的，但無法認為是違法行為。這問題已得到澄清：當授權條款被更改為v2時，就需要提供原始碼的「首選」版本。[57]

授權條款與合同的區別

GPL被設計為授權條款 ，而不是契約[58][59]。在一些普通法（Common Law）司法管轄區，授權條款和契約之間的法律區別是重要的：契約可以透過契約法執行，而授權條款是根據著作權法執行的。然而，這種區別對於契約和授權條款之間沒有區別的許多司法管轄區（如民法系統）並不適用[60]。

GPL原理很簡單：在著作權法下，你不遵守GPL的條款和條件你就沒有相對應的權利。而作品在沒有GPL的情況下，著作權法作為默認條款發生效力，而不是作品進入公有領域。那些不接受GPL條款和條件的人根據著作權法沒有許可複製或分發GPL許可軟體或衍生作品。然而，如果他們不重新分發GPL的程式，他們仍然可以按自己的喜好使用組織內的軟體，使用該程式構建的工程（包括程式）不需要被該授權條款覆蓋。

艾里遜·蘭德爾（英語：Allison Randal）認為，GPLv3作為授權條款對於讀者來說是不必要的混亂，可以在保留相同的條件和法律效力的情況下進行簡化。[61]

衍生或擴展性

GPL的文案本身，受著作權保護 ，著作權由自由軟體基金會持有。GPL的文案本身，卻不在GPL之下。 經許可的著作權不允許修改授權條款。 允許複製和分發授權條款，因為GPL要求收件人獲得「本授權條款與本計劃一起」的副本。 [62]根據GPL常見問題，任何人都可以使用GPL的修改版本，只要他或她使用不同的名稱作為授權條款，不提「GNU」，並刪除前言，儘管如果使用自由軟體基金會（FSF）獲得許可，則序言可以在修改後的授權條款中使用。

FSF允許人們根據GPL新增的授權條款，只要衍生的授權條款未經許可不使用GPL前綴。 然而，這是不鼓勵的，因為這樣的授權條款可能與GPL不相容[62]，並導致感染的授權條款擴散（英語：License proliferation）（license proliferation）。

由GNU專案建立的其他授權條款包括GNU通用公眾授權條款，GNU自由文件授權條款和Affero通用公眾授權條款。

連結和衍生作品

爭議：非GPL軟體是否可以合法地連結或動態地連結到GPL函式庫

據FSF稱，「GPL不要求您發布修改版本，或其任何部分，您可以自由地進行修改和留作私人使用，而無需發布。」然而若是向公眾發布GPL許可的實體，則有連結的問題：換言之，「使用GPL函式庫的專利程式是否違反了GPL ？」

這個關鍵的爭議的重點是「非GPL軟體是否可以合法地連結或動態地連結到GPL函式庫」。這個問題有不同的看法。GPL清楚地表明，GPL下的所有衍生作品代碼都必須屬於GPL。關於使用GPL函式庫和將GPL軟體捆綁到更大的包中（可能透過靜態連結混合成二進位檔案），會出現歧義。這最終不是GPL 本身的問題，而是著作權法如何界定衍生作品。有以下觀點存在：

觀點：動態和靜態連結違反GPL

自由軟體基金會（其擁有若干著名的GPL軟體產品和授權文字本身的著作權）聲稱，使用動態連結函式庫的可執行檔確實是衍生作品。然而，這不適用於彼此通訊的單獨程式。自由軟體基金會還建立了LGPL，LGPL與GPL極為相似，但額外允許以「使用函式庫」為目的的連結。理察·斯托曼和自由軟體基金會特別鼓勵函式庫作者根據GPL來進行授權，以便專有程式無法使用GPL函式庫，透過為自由軟體世界提供比專有世界更多的工具來保護自由軟體世界。

觀點：靜態連結違反GPL，但動態連結則有待釐清

有些人認為，當靜態連結產生衍生作品時，不清楚動態連結到GPL代碼的可執行檔是否應被視為衍生作品（請參閱Weak Copyleft）。Linux作者Linus Torvalds同意動態連結可以建立衍生作品，但在這種情況下不一致。一位Novell律師寫道，動態連結不算是衍生作品的觀點合理但是不夠明確，專有的Linux核心驅動程式就是善意的動態連結的一大明證。在Galoob對任天堂案中，美國第九巡迴上訴法院將衍生作品定義為具有「形式」或「永久性」，並指出「侵權作品必須以某種形式包含一部分受著作權保護的作品」，但是沒有明確的法院裁決來解決這一特定的衝突。

觀點：連結無關

根據Linux Journal的一篇文章， Lawrence Rosen （一次性開源計劃總顧問）認為，連結的方法與一個軟體是否是衍生作品的問題大不相干；更重要的是關於軟體是否旨在與客戶端軟體和/或庫連接的問題。他指出：「新程式是否是衍生工作的主要指示是原始程式的原始碼是否以[複製貼上方式]使用，以任何方式進行修改，翻譯或以其他方式更改新程式，如果沒有，那麼我會認為這不是衍生工作「，並列出了關於意圖，捆綁和聯動機制的許多其他觀點。 他進一步在他公司的網站上論證，這種「以市場為基礎」的因素比連結技術更重要。

還有一個具體問題是，一個外掛程式或模組（如NVidia或ATI 顯示卡核心模組）是否也必須是GPL，如果它可以合理地被認為是自己的工作。這個觀點表明，如果工作是GPLv2，則可以根據任意授權條款，為設計使用外掛程式的軟體提供合理的單獨外掛程式或外掛程式。特別感興趣的是GPLv2段落：

GPLv3有一個不同的條款：

作為一個案例研究，一些據稱為GPLv2 CMS軟體（如Drupal和WordPress）的專有外掛程式和主題/外觀已經受到打擊，雙方均被採納[63][64]

FSF區分外掛程式如何被呼叫。如果透過動態連結呼叫外掛程式，並且它對GPL程式執行函式呼叫，那麼它很有可能是衍生工作。[65]

與非GPL程式的通訊和綁妥

與其他程式通訊的行為本身並不要求所有軟體都是GPL；也不用GPL軟體分發GPL軟體。但是，必須遵循較小的條件，確保GPL軟體的權利不受限制。 以下是gnu.org的 GPL FAQ，該常見問題解答介紹了允許軟體與GPL程式進行通訊和綁妥的程度：

因此，FSF想在「函式庫」和「其他程式」之間透過以下兩種方式劃清界線： 1）資訊交換的「複雜性（complexity）」和「親密程度（intamacy）」；2）資訊交換的「機構（mechanics）「，而不是「語義（semantic）」。但讓問題不明確，而又複雜的情況下，交由判例法來決定。

著作權所有人

GPL文字是著作權所有的，且著作權人是自由軟體基金會。但是，自由軟體基金會沒有在GPL下發行作品的著作權（除非作者指定自由軟體基金會是著作權人）。通常認為，只有著作權人才有權對授權條款的違反進行起訴，但是那並不准確。法國的一個教育組織AFPA於2000年從Edu4購買課堂使用的電腦裝置發現其使用GPL軟體但並未附帶原始碼。 [66][67]

自由軟體基金會允許人們使用以GPL為基礎的其他授權條款，但不允許演繹的授權條款未經授權地使用GPL的前言。不過像這樣的授權條款通常與GPL不相容。[68]

GNU計劃創立的其他授權條款包括：GNU較寬鬆公共許可證和GNU自由文件授權條款。

爭議

一個關於GPL重要的爭議是，非GPL軟體是否可以動態連結到GPL庫。 GPL對GPL作品的演繹作品在GPL下發布規定很明確。但是對於動態連結到GPL庫的作品是否是演繹作品就規定得不清楚了。自由和開放原始碼社群為此分成兩派，自由軟體基金會認為這種作品就是演繹作品，但其他專家並不同意。這個問題根本的並不關乎GPL本身，而是一個著作權法如何定義演繹作品。美國聯邦上訴法院第九巡迴審判庭在Galoob v. Nintendo案對演繹作品嘗試定義，但最終沒有明確的結果。

不幸的是，許多開發人員覺得這是個技術問題。但實際上這完全是法律問題。不過由於迄今為止沒有案例表明有人以動態連結的方式來繞過GPL的條款並因此被起訴，動態連結的限制已經是事實上地（de facto）有效，不論它是否是法律上地（de jure）有效。

2002年，MySQL AB公司起訴Progress NuSphere侵犯著作權和商標。 NuSphere被指以連結代碼的形式侵犯了著作權。最終此案以調解結束。在聽證期間，法官「認為沒有什麼原因」（不管是否是動態連結）會使得GPL失去法律效力。

2003年8月，SCO Group稱他們認為GPL沒有法律效力，且準備就在Linux核心中使用的SCO Unix代碼進行訴訟。參見SCO訴IBM。

2004年4月，在SiteCom拒絕停止發行Netfilter專案的GPL軟體後，慕尼黑地區法庭據對GPL條款的侵犯判定對SiteCom進行臨時性禁令（訴前停止侵犯專利權行為的措施）。同年7月，法庭確認此勒令為對SiteCom最終判決。此判決明顯的印證了自由軟體基金會的法律顧問伊本·莫格林的預言：

「被告侵犯了原告的著作權：提供了軟體netfilter/iptables的廣告及下載，但沒有遵守GPL的條款。可以說，如果被告有授權條款許可，這些行為是完全合法的……原被告就GPL是否達成協定這是一個獨立的問題。如果當事人沒有同意，被告將沒有複製、發行、公開'netfilter/iptables'的權利。」

此判決十分重要，因為它是全球首次法庭確認GPL是有法律效力的。

2005年5月，Daniel Wallace於美國聯邦印第安納南區地方法院起訴自由軟體基金會，因為二者對GPL是否非法意見不一。後訴訟於3月結束，因為Wallace沒有有效的反托拉斯陳述。法庭注意到「GPL鼓勵，而不是反對電腦作業系統的自由競爭和發行，這直接使消費者受益。」[69]Wallace被拒絕改變訴由，並被要求支付訴訟費用。

相容性

大多數自由軟體授權條款，比如MIT/X授權條款、BSD授權條款、LGPL，都是「 GPL相容的」，即它們的代碼與GPL代碼混用無衝突（但新代碼則是GPL下的）。但是有某些開源軟體授權條款不是GPL相容的。通常意見是開發人員僅只使用GPL相容的授權條款，以免法律問題。

參見軟體授權條款列表以查證相容性。

批評

2001年微軟的執行長史蒂夫·巴爾默稱Linux為「癌症」，因為GPL的影響。微軟批評者指出，微軟憎惡GPL的真正原因是因為GPL對微軟的「包圍、擴展、消滅」策略起了反作用。注意微軟已以GPL為授權條款發行了SFU（Microsoft Windows Services for UNIX）中所包含的部分組件，例如GCC。

GPL的批評者常常認為GPL是有「傳染性」的「病毒」，因為GPL條款規定演繹作品也必須是GPL的。由於「演繹作品」通常被解釋為包含GPL代碼或動態連結到GPL庫（如上）的軟體，「病毒說」來源於GPL對於授權條款的強制繼承的要求。這正是GPL與BSD式授權條款的哲學思想上的差異。 GPL的支持者確信自由軟體世界應具有自我保護能力和可持續發展性——確保自由軟體的演繹作品同樣「自由」，但其他人認為自由軟體應給予「所有人」最大的自由。

不同版本之間的GPL並不相容。例如，當原始的作品以GPLv2發布，而補丁以GPLv3發佈時，因為這樣的原因，其編譯之後產生的二進位版本不可以再行傳播。因此，FSF通常會推薦以「GPLv2 or later」這樣的形式來標示授權授權條款，或GPLv2 + GPLv3雙授權條款以規避這一問題。

注釋

  1. ^ 在一些國家裡，人們只能以二進位代碼的形式發布軟體，以保護開發軟體者的著作權。
  2. ^ example: if only GNU Lesser General Public License- (LGPL-) libraries, LGPL-software-components and components with permissive free software licenses are used (thus not GPL itself), then only the source code of LGPL parts has to be made available—for the developer's own self-developed software components this is not required (even when the underlying operating system used is licensed under GPL, as is the case with Linux).
  3. ^ 一個反例是 GPL'ed GNU Bison: the parsers it outputs do contain parts of itself and are therefore derivatives, which would fall under the GPL if not for a special exception granted by GNU Bison: Conditions for Using Bison. [2008-12-11]. （原始內容存檔於2020-08-22）. </ref>

參見

參考文獻

  1. ^ Debian – License information. Software in the Public Interest, Inc. [2009-12-10]. （原始內容存檔於2016-04-22）. 
  2. ^ 2.0 2.1 Licenses – Free Software Foundation. Free Software Foundation. [2009-12-10]. （原始內容存檔於2008-12-16）. 
  3. ^ Licenses by Name. Open Source Initiative. [2009-12-10]. （原始內容存檔於2016-06-06）. 
  4. ^ Copyleft: Pragmatic Idealism – Free Software Foundation. Free Software Foundation. [2009-12-10]. （原始內容存檔於2009-07-01）. 
  5. ^ If a library is released under the GPL (not the LGPL). Free Software Foundation. [2017-05-03]. （原始內容存檔於2016-12-29）. 
  6. ^ 6.0 6.1 Top 20 licenses. Black Duck Software. 2015-11-19 [2015-11-19]. （原始內容存檔於2016-07-19）. 1. MIT license 24%, 2. GNU General Public License (GPL) 2.0 23%, 3. Apache License 16%, 4. GNU General Public License (GPL) 3.0 9%, 5. BSD License 2.0 (3-clause, New or Revised) License 6%, 6. GNU Lesser General Public License (LGPL) 2.1 5%, 7. Artistic License (Perl) 4%, 8. GNU Lesser General Public License (LGPL) 3.0 2%, 9. Microsoft Public License 2%, 10. Eclipse Public License (EPL) 2% 
  7. ^ GPL FAQ: Does using the GPL for a program make it GNU Software? （頁面存檔備份，存於網際網路檔案館）
  8. ^ 开源的许可证GPL、LGPL、BSD、Apache 2.0的通俗解释. [2021-08-30]. （原始內容存檔於2021-08-30）. 
  9. ^ Make Your Open Source Software GPL-Compatible. Or Else.. [2017-05-03]. （原始內容存檔於2021-01-26）. 
  10. ^ Estimating Linux's Size. www.dwheeler.com. [2017-05-03]. （原始內容存檔於2021-01-25）. 
  11. ^ 11.0 11.1 11.2 GPLv3 hits 50 percent adoption. [2017-05-03]. （原始內容存檔於2020-08-22）. 
  12. ^ 存档副本. [2017-05-03]. （原始內容存檔於2020-10-08）. License proliferation: a naive quantitative analysis] on lwn.net "Walter van Holst is a legal consultant at the Dutch IT consulting company mitopics. ... Walter instead chose to use data from a software index, namely Freecode ... Walter's 2009 data set consisted of 38,674 projects ... The final column in the table shows the number of projects licensed under "any version of the GPL". In addition, Walter presented pie charts that showed the proportion of projects under various common licenses. Notable in those data sets was that, whereas in 2009 the proportion of projects licensed GPLv2-only and GPLv3 was respectively 3% and 2%, by 2013, those numbers had risen to 7% and 5%." 
  13. ^ Top 20 licenses. Black Duck Software. 2013-08-23 [2013-08-23]. （原始內容存檔於2016-07-19）. 1. GNU General Public License (GPL) 2.0 33%, 2. Apache License 13%, 3. GNU General Public License (GPL) 3.0 12% 
  14. ^ Why the GPL rocketed Linux to success. [2017-05-03]. （原始內容存檔於2013-06-25）. So while the BSDs have lost energy every time a company gets involved, the GPL'ed programs gain every time a company gets involved. 
  15. ^ 15.0 15.1 Torvalds, Linus. COPYING. kernel.org. [2013-08-13]. （原始內容存檔於2015-12-17）. Also note that the only valid version of the GPL as far as the kernel is concerned is _this_ particular version of the license (ie v2, not v2.2 or v3.x or whatever), unless explicitly otherwise stated. 
  16. ^ Linus Torvalds. Linux-2.4.0-test8. lkml.iu.edu. 2000-09-08 [2015-11-21]. （原始內容存檔於2020-05-15）. The only one of any note that I'd like to point out directly is the clarification in the COPYING file, making it clear that it's only _that_particular version of the GPL that is valid for the kernel. This should not come as any surprise, as that's the same license that has been there since 0.12 or so, but I thought I'd make that explicit 
  17. ^ 《自由软件，自由社会》：什么是自由软件？. [2018-05-20]. （原始內容存檔於2020-08-22）. 
  18. ^ Ball, Patrick. Holbrook, J. , 編. Free Software. Ethics, Science, Technology, and Engineering: A Global Resource (Farmington Hills, MI: Macmillan Reference USA). 2015, 2 (2): 291–295 [2016-11-26]. （原始內容存檔於2019-10-16）. Thus free software may be used and shared by anyone who accepts the terms of the license. The most common free software license is the general public license (GPL). A GPL offers the following: 
  19. ^ GNU Emacs Copying Permission Notice (1985). [2015-11-08]. （原始內容存檔於2020-08-22）. 
  20. ^ The History of the GPL. [2011-11-24]. （原始內容存檔於2020-11-11）. 
  21. ^ 21.0 21.1 Stallman, Richard. Presentation at the second international GPLv3 conference, held in Porto Alegre. 2006-04-21 [2017-05-03]. （原始內容存檔於2009-03-31）. 
  22. ^ Why Upgrade to GPL Version 3 --GPLv3. Fsf.org. [2011-03-17]. （原始內容存檔於2021-01-03）. 
  23. ^ GNU 工程的哲学. [2019-04-16]. （原始內容存檔於2021-01-12）. 
  24. ^ FSF releases the GNU General Public License, version 3 – Free Software Foundation – working together for free software. Fsf.org. [2011-01-15]. （原始內容存檔於2013-06-25）. 
  25. ^ Creative Commons—GNU General Public License. [2010-07-20]. （原始內容存檔於2010-09-25）. 
  26. ^ GNU通用公共授權條款. [2010-07-20]. （原始內容存檔於2010-09-10）. 
  27. ^ 27.0 27.1 Stallman, Richard. Presentation in Brussels, Belgium—the first day of that year's FOSDEM conference.. 2006-02-25 [2006-04-27]. （原始內容存檔於2017-08-25）. 
  28. ^ 28.0 28.1 GPL第三版 GNU General Public License. [2012-06-15]. （原始內容存檔於2017-07-29）. 
  29. ^ Interview with Richard Stallman （頁面存檔備份，存於網際網路檔案館）, Free Software Magazine, 23 January 2008.
  30. ^ A Quick Guide to GPLv3 – GNU Project – Free Software Foundation (FSF). Free Software Foundation. [2017-05-03]. （原始內容存檔於2016-12-29）. 
  31. ^ GPLv3: Drafting version 3 of the GNU General Public License. Free Software Foundation Europe. [2017-05-03]. （原始內容存檔於2009-04-13）. 
  32. ^ gplv3.fsf.org comments for discussion draft 4. [2012-11-23]. （原始內容存檔於2008-10-02）. 
  33. ^ gplv3.fsf.org comments for draft 1. [2012-11-23]. （原始內容存檔於2008-06-26）. Showing comments in file 'gplv3-draft-1' ... found 962 
  34. ^ gplv3.fsf.org comments for draft 2. [2012-11-23]. （原始內容存檔於2008-07-24）. Showing comments in file 'gplv3-draft-1' ... found 727 
  35. ^ gplv3.fsf.org comments for draft 3. [2012-11-23]. （原始內容存檔於2008-07-03）. Showing comments in file 'gplv3-draft-3' ... found 649 
  36. ^ gplv3.fsf.org comments for draft 4. [2012-11-23]. （原始內容存檔於2008-10-02）. Showing comments in file 'gplv3-draft-4' ... found 298 
  37. ^ Guide to the third draft of GPLv3. [2017-05-03]. （原始內容存檔於2017-06-05）. 
  38. ^ Final Discussion Draft. [2007-06-04]. （原始內容存檔於2018-03-05）. 
  39. ^ GPL version 3 FAQ. [2007-06-04]. （原始內容存檔於2017-09-17）. 
  40. ^ Fourth Discussion Draft Rationale (PDF). [2007-06-04]. （原始內容 (PDF)存檔於2017-03-01）. 
  41. ^ Tiemann, Michael. GNU Affero GPL version 3 and the "ASP loophole". OSI. 2007-06-07 [2013-08-19]. （原始內容存檔於2020-08-14）. 
  42. ^ List of free-software licences on the FSF website （頁面存檔備份，存於網際網路檔案館）: 「We recommend that developers consider using the GNU AGPL for any software which will commonly be run over a network」.
  43. ^ Why did you decide to write the GNU Affero GPLv3 as a separate license? （頁面存檔備份，存於網際網路檔案館） on gnu.org
  44. ^ 44.0 44.1 James E.J. Bottomley; Mauro Carvalho Chehab; Thomas Gleixner; Christoph Hellwig; Dave Jones; Greg Kroah-Hartman; Tony Luck; Andrew Morton; Trond Myklebust; David Woodhouse. Kernel developers' position on GPLv3 - The Dangers and Problems with GPLv3. LWN.net. 2006-09-15 [2015-03-11]. （原始內容存檔於2021-01-18）. The current version (Discussion Draft 2) of GPLv3 on first reading fails the necessity test of section 1 on the grounds that there's no substantial and identified problem with GPLv2 that it is trying to solve. However, a deeper reading reveals several other problems with the current FSF draft: 5.1 DRM Clauses ... 5.2 Additional Restrictions Clause ... 5.3 Patents Provisions ... since the FSF is proposing to shift all of its projects to GPLv3 and apply pressure to every other GPL licensed project to move, we foresee the release of GPLv3 portends the Balkanisation of the entire Open Source Universe upon which we rely. 
  45. ^ Petreley, Nicholas. A fight against evil or a fight for attention?. linuxjournal.com. 2006-09-27 [2015-03-11]. （原始內容存檔於2018-03-02）. Second, the war between Linus Torvalds and other Kernel developers and the Free Software Foundation over GPLv3 is continuing, with Torvalds saying he's fed up with the FSF. 
  46. ^ Linus Torvalds says GPL v3 violates everything that GPLv2 stood for （頁面存檔備份，存於網際網路檔案館） Debconf 2014, Portland, Oregon (accessed 11 March 2015)
  47. ^ Kerner, Sean Michael. Torvalds Still Keen On GPLv2. internetnews.com. 2008-01-08 [2015-02-12]. （原始內容存檔於2015-02-12）. "In some ways, Linux was the project that really made the split clear between what the FSF is pushing which is very different from what open source and Linux has always been about, which is more of a technical superiority instead of a -- this religious belief in freedom," Torvalds told Zemlin. So, the GPL Version 3 reflects the FSF's goals and the GPL Version 2 pretty closely matches what I think a license should do and so right now, Version 2 is where the kernel is." 
  48. ^ GPL 3 Overview. Tech LawForum. 2007-06-29 [2013-09-02]. （原始內容存檔於2016-01-09）. 
  49. ^ A Quick Guide to GPLv3 – GNU Project – Free Software Foundation (FSF). Free Software Foundation. [2017-05-03]. （原始內容存檔於2016-12-29）. 
  50. ^ Landley, Rob. Embedded Linux Conference 2013 - Toybox: Writing a New Command Line. The Linux Foundation. [2016-06-24]. （原始內容 (video)存檔於2020-08-16）. GPLv3 broke "the" GPL into incompatible forks that can't share code. ... FSF expected universal compliance, but hijacked lifeboat clause when boat wasn't sinking. ... 
  51. ^ Landley, Rob. CELF 2013 Toybox talk. landley.net. [2013-08-21]. （原始內容存檔於2020-08-07）. GPLv3 broke "the" GPL into incompatible forks that can't share code. ... FSF expected universal compliance, but hijacked lifeboat clause when boat wasn't sinking. ... 
  52. ^ 存档副本. [2017-05-03]. （原始內容存檔於2017-08-25）. 
  53. ^ 53.0 53.1 Selling Free Software. Free Software Foundation. [2017-05-03]. （原始內容存檔於2018-02-07）. 
  54. ^ GPL FAQ: Use GPL Tools to develop non-free programs （頁面存檔備份，存於網際網路檔案館）
  55. ^ GPL FAQ: GPL require source posted to public （頁面存檔備份，存於網際網路檔案館）, Unreleased modifications （頁面存檔備份，存於網際網路檔案館）, Internal Distribution （頁面存檔備份，存於網際網路檔案館）
  56. ^ 56.0 56.1 GPL FAQ: Port program to GNU/Linux （頁面存檔備份，存於網際網路檔案館）
  57. ^ Reasoning behind the "preferred form" language in the GPL. LWN.net. 2011-03-07 [2017-05-03]. （原始內容存檔於2013-12-02）. 
  58. ^ Essay by Stallman explaining why a license is more suitable than a contract. [2017-05-03]. （原始內容存檔於2020-11-12）. 
  59. ^ Eben Moglen explaining why the GPL is a license and why it matters. [2017-05-03]. （原始內容存檔於2008-11-20）. 
  60. ^ Guadamuz-Gonzalez, Andres. Viral contracts or unenforceable documents? Contractual validity of copyleft licenses. European Intellectual Property Review. 2004, 26 (8): 331–339. SSRN 569101 可免費查閱. 
  61. ^ Allison Randal. GPLv3, Clarity and Simplicity. 2007-05-14 [2017-05-03]. （原始內容存檔於2008-10-15）. 
  62. ^ GPL FAQ: Can I modify the GPL and make a modified license?. [2017-05-03]. （原始內容存檔於2010-02-03）. 
  63. ^ Why They’re Wrong: WordPress Plugins Shouldn’t Have to be GPL. Webmaster-source.com. 2009-01-29 [2011-01-15]. （原始內容存檔於2020-09-15）. 
  64. ^ Licensing FAQ. Drupal.org. [2011-01-15]. （原始內容存檔於2015-09-05）. 
  65. ^ Frequently Asked Questions about the GNU Licenses – GNU Project – Free Software Foundation (FSF). Gnu.org. [2011-01-15]. （原始內容存檔於2016-12-29）. 
  66. ^ GNU GPL在法國勝訴. 2009-09-25 [2009-09-25]. （原始內容存檔於2020-08-07） （中文（中國大陸））. 
  67. ^ paris-16.09 .2009.pdf 判決書（法文）. [永久失效連結]
  68. ^ gnu.org. www.fsf.org. [2006-04-27]. （原始內容存檔於2008-09-08）. 
  69. ^ ENTRY GRANTING REASSERTED MOTION TO DISMISS (PDF). [2006-04-27]. （原始內容 (PDF)存檔於2020-01-16）. 

外部連結



）

取自「https://zh.wikipedia.org/w/index.php?title=GNU通用公共许可证&oldid=85183633」