English [en]   ?e?tina [cs]   espa?ol [es]   fran?ais [fr]   italiano [it]   日本語 [ja]   ??? [ko]   polski [pl]   русский [ru]   簡體中文 [zh-cn]  

這是針對英文原版頁面的中文翻譯。

GNU許可證常見問題

This page is maintained by the Free Software Foundation's Licensing and Compliance Lab. You can support our efforts by making a donation to the FSF. Have a question not answered here? Check out some of our other licensing resources or contact the Compliance Lab at [email protected].

目錄

關于GNU工程、自由軟件基金會及其許可證的基本問題

關于理解GNU許可證的一般性問題

為你的程序選擇GNU許可證

發布按照GNU許可證授權的程序

在編寫其他程序時,使用GNU許可證的軟件

作品中結合有按照GNU許可證發布的源代碼

違反GNU許可證的相關問題


“GPL”代表什么?(#WhatDoesGPLStandFor)

“GPL”代表“通用公共許可證”。其中最廣泛使用的許可證是GNU通用公共許可證,簡寫為GNU GPL。它可以進一步簡寫為“GPL”,前提是大家明白這是指向GNU GPL。

自由軟件是不是就意味著要用GPL?(#DoesFreeSoftwareMeanUsingTheGPL)

絕不是那樣—還有許多其他的自由軟件許可證。我們有一個不完全的列表。為用戶提供某些具體自由的許可證就是一個自由軟件。

為什么我應該使用GNU GPL,而不是其他軟件許可證?(#WhyUseGPL)

使用GNU GPL要求所有發布的改進版本都必須是自由軟件。這意味著你可以避免和一個你自己的作品的專有修改版競爭。不過,在某些特殊的情況下,使用更寬泛的許可證會更好。

所有GNU軟件都使用GNU GPL許可證嗎?(#DoesAllGNUSoftwareUseTheGNUGPLAsItsLicense)

大多數GNU軟件包使用GNU GPL,但是也有一些GNU程序(或部分程序)使用更寬泛的許可證,比如LGPL。我們這樣做是戰略性的

使用GPL的軟件就會變成GNU軟件嗎?(#DoesUsingTheGPLForAProgramMakeItGNUSoftware)

任何人都可以按照GNU GPL發布軟件,但是這并不會使發布的軟件變成GNU軟件包。

把一個軟件變成GNU軟件包意味著明確地把它貢獻給GNU工程。這在軟件的開發者和GNU工程達成共識才行。如果你想為GNU工程貢獻軟件,請寫信給<[email protected]>

如果發現可能違反GPL的情況,我應該怎么做?(#ReportingViolation)

你應該報告這個情況。首先,盡量查看事實情況。然后,告知出版者或版權持有者具體的GPL軟件。如果他們是自由軟件基金會,請寫信給<[email protected]>。如果不是,軟件的維護者可能就是版權持有者、或者她能夠告訴你誰是版權持有者,所以請報告給軟件維護者。

為什么GPL允許用戶公開他們的修改版?(#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions)

自由軟件的一個關鍵特點是用戶有自由合作。允許愿意互相幫助的用戶分享問題修復和軟件改進是絕對必要的。

有些人建議不同于GPL的方法,就是要求改進版由原始作者通過。只要原始作者跟得上維護的需求,這個建議可能在實踐上很不錯,但是如果原作者(或多或少)停下來去干別的事或者沒能顧及所有用戶的需求,這個建議就沒辦法了。除了實際操作的問題,該建議也沒有允許用戶互相幫助。

有時,為了防止各種用戶修改版的混淆,人們還建議對修改版進行控制。就我們的經驗來說,混淆不是大問題。Emacs在GNU工程之外有很多版本,但是用戶還是可以區分。GPL要求版本制作者署名,這樣就可以區分版本并保護版本維護者的聲譽。

GPL是否要求修改版的源代碼公開?(#GPLRequireSourcePostedPublic)

GPL不要求你發布你的修改版或者任何一部分修改版。你有自由修改并自用,而不必發布。這個規則也適用于機構(包括公司);機構可以做出修改版并在內部使用而不向其他外部組織發布。

但是如果你以某種方式把修改版向公眾發布,GPL就要求你向用戶提供修改版的源代碼。

因此,GPL允許程序按某些方式發布,而不允許用其他的方式發布;但是,是不是發布由你來決定。

我是否可以在同一個電腦上使用一個GPL程序和另一個無關的非自由程序?(#GPLAndNonfreeOnSameMachine)

可以。

如果我知道有人有一份GPL軟件的拷貝,我是否可以要求他們給我一份?(#CanIDemandACopy)

不。GPL允許一個人制作和發行軟件的拷貝,只是當這個人選擇這樣做的時候。這個人也有權利選擇不發行該軟件。

GPLv2中的“對任何第三方都有效的書面承諾”怎么理解?它是否意味著任何人都可以得到任何GPL程序的源代碼?(#WhatDoesWrittenOfferValid)

如果你書面承諾提供源代碼,那么提出源代碼需求的人應該有資格得到源代碼。

如果你商業發布二進制卻不帶源代碼,那么GPL說你必須提供書面的在晚些時候發布源代碼的承諾。當用戶非商業性的再發布你的二進制時,他們必須附帶這個書面承諾的拷貝。這意味著沒有從你處獲得二進制的用戶仍然可以從你處獲得源代碼的拷貝,只要提供了此書面承諾。

我們要求此書面承諾對第三方有效的理由在于,間接獲得二進制的用戶也能夠從你處獲得源代碼。

GPL說如果發布修改版,它就必須對所有第三方進行“許可證授權…。誰是第三方?(#TheGPLSaysModifiedVersions)

第2節說你發布的修改版必須對所有第三方使用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軟件時,有人要求你簽署NDA,那么請立刻寫信到[email protected]通知我們。

如果違反事件涉及到其他的GPL代碼持有人,請通知該版權持有者,就和你對付其他形式的GPL違反案例一樣。

GPL是否允許使用保密協議發行修改版或beta版軟件?(#DoesTheGPLAllowModNDA)

不。GPL說的是,修改版必須使用GPL所述的全部自由。因此,從你處獲得修改版的人有權重新發布該軟件(無論是否修改)。你不能使用帶有更多限制的條款發布該軟件的任何版本。

GPL是否允許使用保密協議開發修改版軟件?(#DevelopChangesUnderNDA)

是的。例如,你可以簽署一個開發修改版的合同,并同意只有在客戶同意時才能發布你的修改。我們允許這樣做是因為此時GPL的代碼并沒有按照NDA發布。

你也可以將你的修改按照GPL發布給你的客戶,但是只有在客戶同意時才能把它們發布給其他人。此時,GPL代碼也沒有按照NDA發布,或者說也沒有按照任何附加條款發布。

GPL會賦予該客戶再發布此版本的權利。此時,該客戶可能會選擇不執行該權利,但是她擁有該權利。

我想從我的工作中獲得榮譽。我想讓人們知道我寫的代碼。如果使用GPL,我還能這樣做嗎?(#IWantCredit)

你當然可以從你的工作中獲得榮譽。按照GPL發布程序的一個要求就是在版權聲明處寫上你的名字(假設你是版權擁有者)。GPL要求所有的拷貝都帶有適當的版權聲明。

GPL是否允許添加一些條款從而要求使用這些GPL軟件或其輸出的論文說明引用或致謝?(#RequireCitation)

不,GPL不允許這樣做。雖然我們承認合理的引用是學術發表的一個重要部分,但是引用不能作為GPL的附加要求。根據GPLv3的第7(b)節,要求使用GPL軟件的研究論文說明引用了GPL軟件不在GPL的范圍之內,因此這被認為是對GPL的額外限制。并且版權法也不允許添加這種對軟件輸出的要求,無論該軟件是GPL授權,還是其他許可證授權。

為什么GPL要求在每個軟件拷貝里都要包含一份GPL拷貝?(#WhyMustIInclude)

在每個拷貝里都包含許可證是關鍵性的,這樣每個獲得拷貝的人都知道他們的權利是什么。

包含一個指向許可證的URL而非許可證本身也許看起來很不錯。但是你無法保證該URL五年或十年之后的有效性。20年后,今天我們所用的URL可能不再存在了。

無論網絡發生什么變化,唯一能夠確保擁有拷貝的人們還能看到許可證的方法就是在程序中包含許可證的拷貝。

把GNU GPL的拷貝放在我的代碼庫里是不是就算應用了GPL?(#LicenseCopyOnly)

只是在軟件庫里放一份帶有GNU GPL許可證拷貝的文件并不算明確聲明在該軟件庫里的所有代碼都可以按照GNU GPL來使用。而缺少明確的聲明,意味著并不能完全清楚地界定GPL許可證是否真的適用于各個具體的源代碼文件。一份明確的聲明會使這一切清清楚楚。

一個只包含許可證的文件,其中沒有明確說明具體其他文件遵循該許可證,就像是一個帶有一個子程序的文件,而該子程序從來不被其他程序調用。這個比喻也不完美:律師和法庭可能會根據常識判定因為你想讓代碼使用該許可證才把GNU GPL的拷貝放在代碼庫里。他們也有可能不這樣判斷。但是,你為什么留下這樣的問題呢?

你應該在每個源文件里包含這樣的聲明。在程序的README文件里明確說明也是充分有效的,只要該聲明和源代碼是在一起發布的,但是它們很容易被分別處置。為什么要冒讓你的代碼的許可證不能確定的風險呢

這個問題并不是專門針對GNU GPL許可證的。任何自由許可證都有這個問題。

為什么GPL要求在每個軟件拷貝里都要包含一份GPL拷貝?(#NoticeInSourceFile)

你的每個源代碼文件都應該以一個聲明開始,明確陳述該文件的許可證以避免你的代碼和許可證分離。如果只是你的代碼庫的README文件說明了源代碼遵循GNU GPL許可證,那么有人只把源代碼文件復制到其他程序時你該怎么辦?其他內容可能并不能說明該源代碼文件的許可證究竟是什么。它可能會有了其他的許可證,也許什么許可證也沒有(此時它可能會變成非自由代碼)。

在每個代碼文件的起始部分添加版權聲明和許可證聲明會讓事情變得容易和清楚,以上的不確定性就很難立足。

這個問題并不是專門針對GNU GPL許可證的。任何自由許可證都有這個問題。

如果軟件作品不是很長會怎么樣?(#WhatIfWorkIsShort)

如果整個軟件包僅包含很少的代碼—我們使用的標準是少于300行代碼—那么你可以使用一個寬泛授權的許可證,而無需使用GNU GPL這樣的Copyleft許可證。(除非,該代碼非常重要。)此時,我們建議使用Apache許可證2.0

為了節省空間,我是否可以不要GPL的前言或者如何在程序中使用GPL的部分?(#GPLOmitPreamble)

前言和指導是構成完整GNU 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允許你組合某些代碼,這些代碼可以帶有GPLv3本身沒有的額外條款。第7節中有關于此情況的更多信息,包括被允許的額外條款的清單。

我是否可以用非自由的庫編寫自由軟件?(#FSWithNFLibs)

如果你這樣做,那么你的程序將不能在自由的環境下全功能運行。如果你的程序依靠非自由庫來完成某些工作,那么它就不能在自由的環境下做這些工作。如果它依靠非自由庫才能工作,那么它就不能作為像GNU這樣的自由操作系統的一部分;它超出了自由世界的極限。

所以,請你再考慮一下:你是否可以不使用非自由庫來完成同樣的工作?你是否可以寫一個自由的庫來代替那個非自由庫?

如果你的軟件已經使用了非自由庫,那么改變這個可能有點晚了。你還是可以按照程序的現狀來發布它,這比不發布要好一些。但是,請在README中說明該程序的一個不足是使用了非自由庫,并把避免使用非自由庫而完成同樣的事情作為一個任務推薦給大家。請建議那些想繼續為該程序工作的伙伴首先要做的就是擺脫那個非自由的庫。

請注意,把某些非自由庫和GPL自由軟件合并起來可能還有法律問題。請參看關于GPL軟件和GPL不兼容庫的問題來了解更多信息。

我是否可以用專有系統庫連接一個GPL程序?(#SystemLibraryException)

兩版GPL都有關于copyleft的例外,通常成為系統庫例外。如果你用的GPL不兼容庫滿足了系統庫的條件,那么你就不用對這些庫做任何處理而直接使用;整個程序的源代碼發布要求也不包含這些系統庫,即使你發布的是連接了這些庫之后的可執行文件也是一樣。

關于"系統庫"的標準,各版GPL有所不同。GPLv3在第1節明確定義了"系統庫",以將之和"相關源代碼"區別開來。GPLv2的處理略微不同,放在在第3節。

GPL軟件使用非GPL兼容庫會有什么法律問題?(#GPLIncompatibleLibs)

如果你的程序要用到不屬于系統庫例外的庫,那么你需要獲得授權。下面是你可以使用的兩個許可證聲明的例子;一個是GPLv3用的,另一個是GPLv2用的。在兩個例子中,你都應當在每一個需要授權的文件里添加這個聲明。

只有程序的版權持有者能夠合法地依據此條款發布他們的軟件。如果你是自己編寫了整個程序,那么假定你的雇主或學校沒有對此聲稱版權,你是版權持有者—那么你有權批準這個例外。但是如果你的程序要使用其他作者的GPL程序部分,那么你沒有權利批準和其他作者有關的例外。你必須獲得其他程序的版權持有者的授權。

當其他人修改此程序時,他們不必對自己的代碼做同樣的例外聲明—他們有權選擇。

如果你要連接的庫是非自由庫,請同時參看使用非自由庫撰寫自由軟件的部分

如果你使用的是GPLv3,那么你可以按照第7節的描述做出額外授權來達到這個目的。以下的許可證聲明就是一個例子。你必須把括號里的內容換成適合你的程序的內容。如果不是所有的人都能發布你想要連接的庫的源代碼,那么你應當刪去括號內的文字;否則,你只需去掉括號就行。

Copyright (C) [年份] [版權持有者的名字]

本軟件是自由軟件;你可以按照由自由軟件基金會發布的GNU通用公共許可證來再發布該軟件或者修改該軟件;你可以使用該許可證的第3版,或者(作為可選項)使用該許可證的任何更新版本。

本程序的發布是希望它能發揮作用,但是并無擔保;甚至也不擔保其可銷售性或適用于某個特殊的目的。請參看GNU通用公共許可證來了解詳情。

該程序應該同時附有一份GNU通用公共許可證的拷貝;如果沒有,請參看<http://www.nhjpbo.live/licenses>。

GNU GPL版本3第7節的額外授權

如果你通過連接或合并[庫名稱](或者是該庫的修改版)修改該程序或者其任何部分,而受到該庫許可證[庫的許可證名稱]條款的制約,本程序的許可證授權你輸送修改結果的額外權利。{修改結果的非源代碼形式的相關源代碼應當包含所用[庫名稱]的源代碼部分和本軟件的源代碼部分。}

如果你使用的是GPLv2,那么你可以提供你自己的許可證例外。以下的許可證聲明就是一個例子。同樣地,你必須把括號里的內容換成適合你的程序的內容。如果不是所有的人都能發布你想要連接的庫的源代碼,那么你應當刪去括號內的文字;否則,你只需去掉括號就行。

Copyright (C) [年份] [版權持有者的名字]

本軟件是自由軟件;你可以按照由自由軟件基金會發布的GNU通用公共許可證來再發布該軟件或者修改該軟件;你可以使用該許可證的第2版,或者(作為可選項)使用該許可證的任何更新版本。

本程序的發布是希望它能發揮作用,但是并無擔保;甚至也不擔保其可銷售性或適用于某個特殊的目的。請參看GNU通用公共許可證來了解詳情。

該程序應該同時附有一份GNU通用公共許可證的拷貝;如果沒有,請參看<http://www.nhjpbo.live/licenses>。

靜態或動態把[你的程序名稱]和其他模塊連接在一起就是在[你的程序名稱]的基礎上做工作。因此,GNU通用公共許可證的條款會覆蓋到整個合并的工作。

另外,作為一個特例,[你程序的名稱]的版權持有者賦予你把[你程序的名稱]和自由軟件或按照GNU LGPL發布的庫合并的權利,其中[庫的名稱]標準發布代碼使用[庫的許可證](或者該代碼的修改版,許可證不變)。你可以復制和發布該系統,其許可證條款是[你程序的名稱]使用的GNU GPL許可證和其他代碼{, 假定你按照GNU GPL的發布要求包含了其他程序的源代碼}使用的相關許可證。

請注意,修改[你程序的名稱]的人沒有義務為他們的修改版賦予該特例;這是他們的選擇。GNU通用公共許可證允許無特例發布修改版;該特例也使發布的修改版繼續帶有此特例成為可能。

我如何才擁有我的程序的版權從而可以把它按GPL發布?(#HowIGetCopyright)

按照伯爾尼公約,任何寫出來的東西在其形式固定時就自動獲得版權。所以,你對自己寫的東西不必做任何事就“獲得”其版權—只要沒有其他人聲稱擁有你的作品。

不過,注冊版權在美國是一個好主意。這對你處理在美國的侵權更有利。

其他人可能聲稱對你的作品擁有版權的情況是你是一個雇員或學生;此時,雇主或學校可能會主張你是為他們工作的,所以他們擁有版權。他們的主張是否有效取決于當地的法律、雇傭合同和工作性質等。如果有疑問,最好是咨詢律師。

如果你覺得雇主或學校可能會有所主張,那么你可以通過讓公司或學校的授權人簽署版權免除聲明來解決此問題。(你的上司或教授通常沒有權利簽署這樣的免除聲明。)

如果我的學校想把我的程序變成它的專有軟件,那么我應該怎么辦?(#WhatIfSchool)

當下,許多大學會通過限制使用它們開發的知識和信息來獲取資金,這種行為和商業公司沒什么分別。(請同時參看“被收買的大學”,Atlantic月刊,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類似的工具已經允許用來開發非自由軟件,所以我們也決定這樣做。

我是否有“合理使用”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(不是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解釋器是按照什么許可證發布的。

我使用Microsoft Visual C++編寫一個Windows應用,我要把它以GPL發布。GPL是否允許我的程序動態連接Visual C++運行庫?(#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調用插件,并沒有建立密切的通信,那么插件就是一個單獨的程序。

如果主程序動態連接了插件,而且它們之間互相調用函數并共享數據結構,那么我們認為它們構成了一個單一的組合程序,主程序和插件必須被當作一個擴展來對待。如果主程序動態連接了插件,但是它們之間的通信限于調用插件的‘主’函數及其參數并等待其返回,那么這就是個可以算單一組合程序也可以算兩個獨立程序的臨界情況。

使用共享內存來交換復雜數據結構的情況和動態連接基本類似。

我寫了一個GPL程序的插件,我要發布我的插件的話,我要使用的許可證有什么強制要求?(#GPLAndPlugins)

請參考這個問題來確定什么時候插件和主程序是一個單一的組合程序以及什么時候他們是獨立的兩個程序

如果主程序和插件是一個單一的組合程序,那么就意味著插件必須按照GPL或GPL兼容的自由軟件許可證發布,包括其源代碼。如果主程序和插件是獨立的兩個程序,那么主程序的許可證對插件沒有要求。

我為非自由軟件寫的插件可以使用GPL許可證嗎?(#GPLPluginsInNF)

請參考這個問題來確定什么時候插件和主程序是一個單一的組合程序以及什么時候他們是獨立的兩個程序

如果它們構成了一個單一的組合程序,那么組合GPL的插件和非自由主程序是違反GPL的。不過,你可以通過給插件的許可證添加一個例外來解決這個法律問題,例外就是允許把它和非自由的主程序連接在一起。

請同時參考這個問題我在使用一個非自由的庫來編寫自由軟件。

一個非自由軟件是否可以加載GPL插件?(#NFUseGPLPlugins)

請參考這個問題來確定什么時候插件和主程序是一個單一的組合程序以及什么時候他們是獨立的兩個程序

如果它們構成一個一個單一的組合程序,那么主程序就必須按照GPL或GPL兼容的自由軟件許可證發布,這時發布的主程序如果要使用這些插件,那么GPL的條款必須被遵循。

不過,如果它們是獨立的作品,那么插件的許可證對主程序沒有要求。

請同時參考這個問題我在使用一個非自由的庫來編寫自由軟件。

你有一個GPL程序,我想把該程序和我的代碼連接起來并構造一個專有軟件。該連接是否意味著我必須要把我的程序按照GPL授權?(#LinkingWithGPL)

不準確。這意味著你必須按照和GPL兼容的許可證發布你的程序(更準確地說,是和一個或多個被程序的其他部分代碼所接受的GPL版本的GPL兼容)。然后,該組合程序就要遵守這些GPL的版本。

如果是這樣,那么我還有沒有機會按照LGPL獲得你的程序?(#SwitchToLGPL)

你可以這樣問,但是大多數作者都會堅定地回答不。GPL的思想就是如果你想在程序中包含我們的代碼,那么你的程序也必須是自由軟件。它就是要讓你的程序成為社區的一部分。

你當然總是可以合法地不用我們的代碼。

發布和要Linux內核連接起來的非自由驅動是否違反GPL?(#NonfreeDriverKernelLinux)

Linux(GNU/Linux操作系統的內核)是按照GNU GPLv2發布的。發布一個要和Linux連接的非自由驅動是不是違反GPL?

是的,這是一個違反GPL的場景,因為這實際上是在制作一個較大的組合作品。期待用戶把不同的東西組合在一起并不改變這個場景。

每個擁有一定量代碼的Linux貢獻者都可以要求對此執行GPL,而我們也鼓勵他們對發布非自由Linux驅動的行為采取行動。

我如何才能允許只在可控的接口下連接專有模塊和GPL庫?(#LinkingOverControlledInterface)

請把以下文字添加到你發布的每個文件的許可證聲明里,文字的最后說此文件以GNU GPL發布:

把其他模塊靜態或動態地和ABC連接都構成基于ABC的組合作品。因此,整個組合都遵循GNU通用公共許可證的條款。

作為一個特例,ABC的版權持有者允許你將ABC和自由軟件或以GNU LGPL發布的庫組合,而且這些庫只通過ABCDEF接口和ABC通信。你可以對ABC按照GNU GPL發布、對其他相關代碼按照其相關許可證發布,前提是你按照GNU GPL的發布要求提供了相關的源代碼并且你沒有更改ABCDEF接口。

請注意,修改了ABC的人并沒有被要求獲得對修改版的例外;他們有權選擇是否這樣做。GNU通用公共許可證允許沒有例外地發布修改版;該例外也使按照例外來發布后續的修改版成為可能。如果你修改了ABCDEF接口,那么該例外就不適用于你修改過的ABC,而你則必須在發布修改版時將此例從許可證聲明中移除。

此例外是GNU通用公共許可證第3版第7節的附加許可。(“GPLv3”)

此例外允許使用特定接口(“ABCDEF”)連接帶有不同許可證的模塊,同時確保用戶仍然像使用GPL一樣收到源代碼。

只有程序的版權持有者才能在法律上有效地授權該例外。如果你自己寫了整個程序,并假定你的雇主或學校沒有聲稱對此擁有版權,那么你就是版權持有者—因此你就可以做出此例外的授權。但是如果你想在你的程序中使用其他人的GPL程序,那么你不能代表其他人做出此例外的授權。你必須獲得其他版權持有者的批準。

我寫的應用連接了許多不同的部件,這些部件有多種許可證。我對自己的應用該使用什么許可證很迷惑。你是否能夠告訴我可以使用什么許可證?(#ManyDifferentLicenses)

要回答這個問題,我們需要看看程序使用的部件的列表、這些部件的許可證以及你的程序如何使用這些部件的簡述(幾句話就行)。兩個例子如下:

  • 要正常使用我的軟件,必須把它和FOO庫連接在一起,該庫使用LGPL許可證。
  • 我們的程序需要通過系統調用(使用我的命令行)來運行BAR程序,該程序使用的許可證是“GPL,并帶有允許連接QUUX的例外”。
“聚合版”和其他“修改版”有什么不同?(#MereAggregation)

“聚合版”包含有多個獨立的程序,并在同一個CD-ROM或其他媒體上發行。GPL允許你制作并發布一個聚合版,即使其他軟件的許可證不是自由許可證或不是GPL兼容的許可證也可以。唯一的條件是你的聚合版的許可證不能禁止用戶行使每個獨立程序的許可證允許的權利。

究竟怎么區分是兩個獨立的程序,還是一個程序的兩個部分呢?這是一個法律命題,最終會由法官來決定。我們相信合理的標準既依賴于通信的機制(exec、pipes、rpc、共享地址空間的函數調用,等等),也依賴于通信的語義(交換了什么樣的信息)。

如果兩個模塊都包含在同一個可執行文件里,那么它們一定是一個程序的組件。如果兩個模塊運行時是在共享地址空間連接在一起的,那么它們幾乎也構成一個組合軟件。

反過來,pipes、sockets和命令行參數通常都是兩個不同程序通信的機制。因此,如果使用它們來通信,這些模塊正常應該是獨立的程序。但是如果通信的語義非常密切,交換復雜的內部數據結構,那么它們也被會認為是一個大程序的兩個組合部分。

當判別兩個軟件是否構成單一的作品時,代碼是在一個容器里還是在多個容器里有沒有影響?(#AggregateContainers)

不,容器的引入并不改變他們是單一作品還是聚合版本的分析。

為什么FSF要求對FSF有版權軟件的貢獻者把版權賦予FSF?如果我有GPL軟件的版權,我也需要這樣做嗎?如果需要,我應該怎么做?(#AssignCopyright)

我們的律師告訴我們,如果要在法庭上面對違反者處于最有利于GPL的執法位置,我們就應當是程序的版權狀態越簡單越好。我們的方式是,請每位貢獻者或者把版權賦予FSF,或者對版權做出免責聲明。

我們還請個人貢獻者從其雇主(如果有的話)獲得版權免責聲明,這樣我們就可以確保雇主們不再對此主張版權。

當然,如果所有的貢獻者都把代碼放到共有領域,那么就沒有必要對無版權的代碼進行GPL執法了。所以,我們鼓勵人們對大型代碼貢獻主張版權,而把小型的代碼置于公共領域。

如果你想對你的程序進行GPL執法,那么你最好也使用類似的政策。請聯系<[email protected]>來了解更多信息。

我是否可以修改GPL并制作一個修改版的許可證?(#ModifyGPL)

你可以做一個修改版的GPL,但是這實際上會有一些后果。

你可以合法地在另一個許可證里使用GPL的術語(可能是改過的術語),假定你的許可證叫另一個名字并且不帶有GPL的前言,而且你修改過的操作指導也和GPL有足夠明顯的區別,你也沒有提及GNU(雖然實際的操作流程和GPL是類似的)。

如果你想在修改版的許可證中使用我們的前言,請寫信到<[email protected]>獲得許可。為此,我們會希望檢查實際的許可證要求來決定是否批準。

雖然我們對這樣的修改版不會提起法律上的反對,但是我們還是希望你再考慮一下,最好不要這樣做。這種修改版的許可證幾乎可以肯定和GNU GPL不兼容,而這種不兼容會阻止軟件模塊的合理組合。不同自由軟件許可證的數目增加本身只是一種負擔。

請不要修改GPL,請使用GPLv3提供的例外機制。

如果我通過GNU GPL獲得了一個軟件,那么我是否可以修改該軟件的代碼,把它變成一個新的程序,然后再按照商業程序發行和銷售?(#GPLCommercially)

我們允許你商業化銷售修改版的軟件,但是只有在遵循 GNU GPL 條款的情況下。因此,舉個例子,你必須按照 GPL 的要求使用戶可以拿到源代碼,并且用戶也必須能夠再發布和修改該程序。

這些要求是在你的程序里包含 GPL 代碼所必須的。

GPL可以不用于軟件嗎?(#GPLOtherThanSoftware)

你可以將 GPL 用于任何作品,只要能說清楚什么是該作品的“源代碼”就行。GPL 將源代碼定義為修改作品的首選形式。

然而,對于手冊和教材,或者任何用于教育的一般性作品,我們推薦使用 GFDL 而不是 GPL。

LGPL和Java如何在一起運作?(#LGPLJava)

請參看此文了解詳情。LGPL 可以按照既定的、期望的和預想的方式運作。

考慮這個情況:1) X按照GPL發布了V1。2) Y在V1的基礎上貢獻了修改和新代碼,開發了V2。3) X想要把V2變成非GPL許可證。X需要Y的許可嗎?(#Consider)

是的。由于 Y 是基于 X 的 V1 版本做出的,所以 Y 要按照 GNU GPL 發布。Y 不必就其代碼同意使用任何其他的許可證。所以,X 要想按照其他協議發布 V2,必須要獲得 Y 的許可。

我想在我的專有系統中合并GPL軟件。我只按照GPL授予的方式使用該軟件。我可以這樣做嗎?(#GPLInProprietarySystem)

你不能把 GPL 軟件結合到專有系統中去。GPL 的目標是賦予所有人復制、發布、理解和修改程序的自由。如果你把 GPL 軟件結合進一個非自由的系統,那么它的效果就和把 GPL 軟件變成非自由軟件一樣。

一個結合了 GPL 程序的程序就是該 GPL 軟件的擴展版。GPL 指出任何擴展版如果要發布都必須按照 GPL 來發布。這有兩個理由:確保得到軟件的用戶得到他們應得的自由,鼓勵人們回饋他們做出的改進。

不過,在許多情況下,你可以和 GPL 軟件一起發布你的專有軟件。你的所作要合法,你要確保自由和非自由的軟件之間的隔離,它們之間的通信不應該看起來是一個組合在一起的程序的行為。

這樣做和“結合” GPL 軟件的不同有內容的因素也有形式的因素。內容的因素在于:如果兩個程序組合在一起實際上變成了一個程序的兩個部分,那么你就不能再把它們當成兩個程序來看待。因此 GPL 必須涵蓋到整個系統。

如果兩個程序隔離地很好,正如編譯器和內核,也如編輯器和 shell,那么你可以把他們當成兩個獨立的程序—但是你的做法必須合理。這個問題就是簡單的形式:你如何描述你在做什么?為什么我們要關心這個?因為我們要確保用戶清晰地理解整個集合中 GPL 軟件的自由狀態。

如果要發布 GPL 軟件的人稱之為專有系統的“一部分 ”,那么用戶也許不確定他們對其中 GPL 軟件的權利。但是如果用戶知道他們得到一個自由的程序加上另一個程序,那么他們的權利就是清晰的。

我想在我的專有系統中結合GPL軟件?我是否可以在GPL軟件和專有系統之間制作一個使用松散的GPL兼容許可證(比如X11許可證)的“封裝”模塊?(#GPLWrapper)

不行。X11 許可證和 GPL 是兼容的,因此你可以在 GPL 軟件中添加一個遵循 X11 許可證的模塊。但是,如果你想把這兩個都合進一個更大的程序,包括這個 GPL 軟件,那么整個程序就必須遵循 GNU GPL 許可證。

專有模塊 A 和 GPL 許可證模塊 C 通過 X11 許可證模塊 B 通訊這件事在法律上并不相關;重要的是模塊 C 被包含在整個軟件中。

哪里可以了解更多關于GCC運行庫例外的詳情?(#LibGCCException)

GCC運行庫例外涵蓋了 libgcc、libstdc++、libfortran、libgomp、libdecnumber 以及其他和 GCC 一起發布的庫。該例外意在允許人們在發布使用GCC編譯的程序時能夠使用自己選擇的條款,即使該程序經過編譯形成的可執行文件包含了這些庫的成分。如需更多信息,請參閱 關于 GCC 運行庫例外的常見問答

我想修改GPL程序并把它們和Money Guzzler Inc的可移植庫連接在一起。我不能發布這些庫的源代碼,所以每個想修改的用戶都要單獨獲得這些庫。為什么GPL不允許這樣做?(#MoneyGuzzlerInc)

有兩個原因。第一,常規的原因。如果我們允許甲公司制作一個專有文件,而乙公司發布一款連接著此文件的GPL軟件,那么這個漏洞就會使整個GPL許可證陷入泥潭。這將成為人們拒不發布對GPL軟件的修改和擴展的護身符。

讓所有用戶都有權獲得源代碼是我們的主要目標之一,因此我們絕對要避免上述情況的出現。

更具體地來說,和 Money Guzzler 的庫連接在一起的程序不是我們所定義的真正意義上的自由軟件——它們沒有全部的源代碼,因而用戶也無法修改和再編譯整個程序。

如果模塊Q的許可證要求和GPL不兼容,不過該要求只適用于單獨發布Q的情況,而不是當Q被包含在一個大型程序中,那么該許可證和GPL兼容嗎?我是否可以把Q和GPL程序聯合或連接起來?(#GPLIncompatibleAlone)

一個程序 P 按照 GPL 發布就意味著“其任意部分”都可以按照 GPL 來使用。如果你集成了模塊 Q,并且將組合程序 P+Q 按照 GPL 發布,那么 P+Q 的任意部分都可以按照 GPL 來使用。P+Q 的一個部分就是 Q,所以 Q 的任意部分也是可以按照 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 v3 允許這樣做;請參考選項 6(b) 來了解詳情。在GPL v2 中,你當然可以通過 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 程序做個比較,這些 GPL 程序在用戶訪問網站時分發給了用戶(經常是JavaScript程序,但是也可以使用其他語言)。此時,這些發布給用戶的程序的源代碼必須按照 GPL 的條款來發布。

某公司在網站上運行一個許可證為GNU Affero GPL (AGPL)的程序的修改版。按照AGPL,該公司是否必須發布其修改版的源代碼?(#UnreleasedModsAGPL)

GNU Affero GPL 要求該修改版軟件為其用戶提供一個通過計算機網絡獲取源代碼的方法。你所說的公司正處在這樣一個狀態下,所以它必須發布修改版軟件的源代碼。

在組織或公司內部使用是不是“發布”? (#InternalDistribution)

不是,在公司內部使用只是公司為自己制作拷貝。因此,公司或組織可以開發自己的修改版并在內部部署,其員工也無權對外發布。

然而,當公司把拷貝發送給其他組織或個人時,就是發布。具體來說,為合同商提供拷貝來離岸使用就是發布。

如果某人盜取了一張含有GPL軟件的CD,那么GPL是否授權此人再發布該軟件?(#StolenCopy)

如果該版本已經發布了,那么竊賊或許有權制作拷貝并按照 GPL 再發布,但是如果竊賊因為盜竊 CD 入獄了,那么可能只好等他出來再發布了。

如果被盜的版本沒有公開,并且有公司認為它是商業機密,那么發布該版本可能在此情況下就是違反了商業機密法。GPL 并不改變這一點。如果該公司要發布該版本并且仍然把它看作是商業機密,那么該公司就違反了 GPL;但是如果該公司沒有發布該版本,那么它就沒有違反 GPL。

如果公司按照商業秘密來發布他人的 GPL 作品拷貝會怎么樣?(#TradeSecretRelease)

該公司違反了 GPL 并且必須停止發布。請注意這和上面的盜竊問題不同;軟件拷貝遭到盜竊時,公司并未有意發布該軟件,因此公司沒有違反 GPL。

如果公司按照商業秘密來發布自己的 GPL 作品拷貝會怎么樣?(#TradeSecretRelease)

如果此發布程序中不包含其他人的 GPL 作品,那么該公司沒有違反 GPL(更多信息,請參看 “GPL程序的開發者和GPL綁定了嗎?”)。但是它在你如何使用該程序的問題上作出了自相矛盾的陳述:你既可以再發布之,又不可以再發布之。在你接受程序拷貝之前,你最好是要求它就如何使用該程序作出明確解釋。

為什么有些GNU庫是按照普通的GPL發布,而不是按照LGPL發布?(#WhySomeGPLAndNotLGPL)

對具體的庫采用寬 GPL 許可證實際上自由軟件的倒退。這意味著我們部分放棄了對用戶自由的保護,也部分放棄了一些 GPL 軟件應有的要求。就事論事,這些放棄都是壞事。

有時,局部的倒退是一個不錯的策略。在適當的情況下,對庫采用 LGPL 會讓這些庫被更廣泛地使用,因此就更多地改善了這些庫、更多地支持了自由軟件等等。如果范圍很大,那么這就是對自由軟件有益的事。但是它究竟會怎么發展呢?我們拭目以待。

如果能夠對每個庫都試行一段時間的 LGPL 來看看效果如何,若是沒有什么幫助再改回 GPL 是最好的。但是這個做不到。一旦我們對一個具體的庫使用了 LGPL,那么我們就很難再改回來。

因此,我們對哪個庫使用什么許可證采用的是具體情況具體分析的原則。請參看我們關于如何判斷的詳細解釋

使用按照GPL發布的GNU程序不適合我們的專有軟件項目。你們會對我們例外嗎?這樣會使更多人使用你們的程序。(#WillYouMakeAnException)

對不起。我們不會對此提供例外。這樣的例外是錯誤的。

使用戶數量最大化并不是我們的目標。更準確地說,我們是要給予盡可能多的用戶關鍵的自由。一般來說,專有軟件會妨礙而不是助力自由。

我們偶爾也會允許許可證例外,并以此來幫助使用不同于 GPL 許可證的自由軟件項目。然而,我們這樣做時必須要看它對推進自由的充分理由。

我們有時也會更改軟件包發行的條款,只要它是一條清晰的為自由軟件服務的正確道路;但是,我們對此也分外小心,因此你的理由必須令人信服。

為什么程序應該寫上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——但是他們還是被要求按照版本 3 來使用軟件。這些用戶可能無意中已經違反了許可證條款,只是因為他們不知道有新的許可證版本。這對他們不公正。

除非是因為有違反許可證的情況,我們認為收回已經授予的許可是錯誤的。如果自由可以撤銷,那么它就不是真正的自由。因此,如果你在某個許可證版本下得到了軟件,那么你就應該 一直 擁有在該許可證版本下被授予的權利。按照 “GPL 版本 N 或者任何以后的版本” 發布維持了這個原則。

WhyNotGPLForManuals">為什么手冊不用GPL?(#WhyNotGPLForManuals)

GPL 可以用于手冊,但是 GNU 自由文檔許可證(GFDL)更適合手冊。

GPL 本來就是為程序設計的;它的很多復雜條款對程序來說是關鍵的,但是它們對手冊或書籍來說就太累贅而沒有必要了。例如,任何出版紙質書的人如果沒有隨書提供該書的機器可讀“源代碼”,就必須提供隨后會寄送該“源代碼”的書面承諾。

同時,GFDL 的條款有助于自由手冊的出版商通過銷售拷貝賺錢——比如,使用封面文字。GFDL 的背書部分特有的條款使之有可能成為一個正式的標準。它允許修改版,但是修改版不能帶有“標準”字樣的標簽。

使用 GFDL,我們允許修改手冊中有關技術的內容。修改技術部分非常重要,因為修改軟件的人應該有權修改相應的文檔。這個自由是一個道德底線。

我們的手冊還有一個闡述我們對自由軟件的政治立場的章節。我們將此標記為“不變章節”,因此它們不能夠被改變,也不能被刪除。GFDL 為這些“不變部分”準備了條款。

GPL如何應用于字體?(#FontException)

字體的許可證是一個需要認真考慮的復雜問題。以下許可證例外是實驗性的,但是已經獲準常規性的使用。我們歡迎對此問題的建議——請參看此文的解釋并寫信給[email protected]

要使用該例外,請在軟件包(最大的范圍內)的每個文件的許可證聲明前添加以下文字,在文字的最后說明此文件使用 GNU GPL 授權發布:

作為例外,如果你的文檔使用了這個字體,并且將字體或部分字體沒有改變地嵌入到文檔中,那么,該字體本身并不導致此文檔就是要遵循 GNU GPL 許可證。不過,此例外并不排除該文檔可能需要遵循 GNU GPL 的其他理由。如果你修改了該字體,那么你也可以此例外推廣到心版本的字體,但是這并不是強制的。如果你不想這么做,那么你可以把這個例外在你的版本里刪掉。

我在編寫一個網站維護系統(有人稱之為“內容管理系統”),或者是其他通過模板創建網頁的應用。這些模板應該使用什么樣的許可證呢?(#WMS)

模板太輕量級了,還不足以動用 copyleft 來保護。一般來說,對輕量級的作品使用 copyleft 并沒有害處,但是模板有點例外,因為它們和用戶數據結合在一起,而且一起發布。所以,我們建議對模板使用簡單許可性條款。

有些模板會調用 JavaScript 函數。由于 Javascript 通常不是微不足道的功能,它值得使用 copyleft。因為模板會和用戶數據結合在一起,所以模板+用戶數據+JavaScript可以考慮做成一個作品并受版權保護。JavaScript(copyleft)和用戶代碼(通常使用和copyleft不兼容的條款)應該有明確的界限。

以上內容的圖解

以下是針對此類 JavaScript 代碼做的例外示范:

作為 GPL 的一個特定例外,任何 HTML 文件,如果僅僅是調用了該代碼,并因此作為引用包含了該代碼,那么該文件就應該按照版權法的考慮作為一個獨立的作品。另外,此代碼的版權持有者授權你可以將該代碼和按照 GNU GPL 許可證發布的自由軟件庫組合在一起。你可以按照 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,那么你應該通知該 GPL 軟件的開發者。他們要不就是版權持有者,要不就是和版權持有者有關系。請了解更多關于違反 GPL 的信息。

在一個面向對象的語言,比如Java下,如果我不加修改地使用了一個GPL類,并做成了子類,那么GPL會對更大范圍的程序有什么影響?(#OOPLang)

創建子類也是在創建衍生作品。因此,GPL 的條款會影響包含了被創建的 GPL 子類的父類的軟件。

如果我把我的程序移植到GNU/Linux,那么這是否意味著我必須按照GPL或其他自由軟件許可證發布我的軟件?(#PortProgramToGPL)

一般來說,回答是否定的—這不是法律上的要求。具體來說,回答依賴于你要用的庫以及這些庫的許可證。大多數系統庫不是使用 GNU LGPL,就是使用 GNU GPL 加上一個允許該庫連接任何程序的例外條款。這些庫可以用于非自由的程序;但是就 LGPL 許可證來說,它還是有一些你必須遵守的要求的。

有些庫是只以 GNU GPL 發布的;你必須使用和 GPL 兼容的許可證才能使用這些庫。但是這些通常是更加專用的庫,并且在其他平臺上你也很難找到類似的庫,所以對于簡單的程序移植你可能不太會涉及這些庫。

當然,如果你的軟件是非自由的,那么它并沒有對我們的社區做貢獻,而看重自由的人是不會用這種軟件的。只有要放棄自由的人才會使用你的軟件,這意味著該軟件實際上是在誘使人們失去自由。

如果你希望將來回首往事的時候,你的軟件曾經為建設美好和自由的社會做出了貢獻,那么你需要讓它成為自由軟件。

我發現有個公司有一個GPL軟件的拷貝,但是要花錢才能拿到該軟件。這個公司是否因此違反了GPL?(#CompanyGPLCostsMoney)

不。GPL 并不要求人們使用互聯網來發布程序。它也沒有要求某個特定的人來再發布程序。而且(除了一個特定的場景),如果有人決定要再發布一個程序,GPL 也沒有說他必須把程序發布給你或這任何特定的人。

GPL 要求的是如果他愿意,他有自由為你發布一份該程序的拷貝。一旦版權持有者發布了程序的拷貝給某個人,那么這個人就可以再發布拷貝給你或其他人,只要他覺得合適。

我是否可以發布一款軟件,它的許可證是你可以按GPL發布此軟件的修改版,但是你不能按GPL發布此軟件的原始版?(#ReleaseNotOriginal)

不行。這樣的許可證自相矛盾。讓我們看看它對作為用戶的我意味著什么吧。

假定我從原始版本(版本甲)開始,并添加了一些代碼(比如 1000 行),而后按照 GPL 發布了該修改版(版本乙)。GPL 說任何人可以再修改版本乙并按照 GPL 發布。所以我(或其他人)可以刪掉這 1000 行代碼,制作版本丙。版本丙的代碼其實和版本甲一樣,但是版本丙是遵循 GPL 的。

如果你想攔住這條去路,在許可證中明確說我不能通過刪除版本乙的代碼制作和版本甲一樣的程序,不過是遵循 GPL 許可證的,那么你的許可證實際上是在說我不能完全按照 GPL 許可證使用版本乙。換句話說,你的許可證實際上不允許用戶按照 GPL 發布一個修改版,比如版本乙。

把軟件拷貝移送到一個由多數人擁有并控制的機構是否構成發布?(#DistributeSubsidiary)

把軟件拷貝移送到或者從該機構拿出來是否構成 “發布” 是一件按照版權法在法庭里決定的事。GPL 不會也不能超越適用地的法律。美國法律對此也沒有清晰的界定,但是傾向于認為這不是發布。

如果在某些國家,這個被認為是發布,那么該機構就必須獲得再發布該軟件的權利,實際上也是這樣做的。如果該機構由一個母公司控制,那么有沒有再權發布就由母公司說了算。

軟件安裝程序是否可以要求人們通過點擊同意GPL?如果我得到一份GPL軟件,那么我必須同意什么嗎?(#ClickThrough)

有些軟件的安裝系統有一個要求你點擊同意 GPL 的地方,否則就意味著同意了 GPL 的條款。這不是要求,也不被禁止。點不點擊同意,GPL 的條款并不會改變。

單是同意 GPL 并沒有對你強加什么義務。你沒有被要求同意任何事才能使用 GPL 軟件。只有你修改或分發該軟件時,你才有義務。如果你覺得點擊同意 GPL 有問題,那么沒有人可以阻止你改寫該 GPL 軟件并跳過點擊同意。

我想把GPL軟件和一些安裝程序合在一起。這些安裝程序也必須是GPL軟件嗎?(#GPLCompatInstaller)

不。安裝程序和被安裝的文件是分別的作品。因此,GPL 條款不應用于該安裝程序。

如果發布者要求我“表明并保證”我住在美國或者我有意遵循相關出口管制法律來發行該軟件,那么該發布者是否違反了GPL?(#ExportWarranties)

這并不是違反 GPL。這些分發商(幾乎所有此類分發商都從事著銷售自由軟件和相關服務的商業活動)是在降低他們自己的法律風險,而不是在控制你的行為。美國的出口管制法可能會使承擔責任,如果他們明知故犯地把軟件出口到某些國家或者把軟件交給可能會這樣做的第三方。通過獲取他們客戶或伙伴的此類聲明,他們就能夠在以后被監管機構盤查分發軟件的去向之時保護自己。他們并不是在限制你對軟件的做法,他們只想避免因你的所作所為而受到牽連。因為他們沒有對軟件添加額外的限制,所以他們沒有違反 GPLv3 的第 10 節或 GPLv2 的第 6 節。

FSF 抵制把美國出口管制法律應用于自由軟件。這些法律不但和自由軟件的總目標不兼容,而且這些法律也沒有實現任何有意義的政府目標。因為自由軟件現在已經被幾乎所有國家所用而且將來也應該這樣,包括那些沒有出口管制法的國家和沒有參加美國主導的貿易禁運活動的國家。因此,實際上沒有政府被美國的出口管制法剝奪了自由軟件,反之,對我們而言,任何國家的公民都不應該被剝奪自由軟件,無論他們的政府政策是什么樣的。不管你住在哪里,也不管你要干什么,你都可以從我們這里獲得由 FSF 發布的所有 GPL 軟件的拷貝。與此同時,FSF 理解美國的商業分銷商遵守美國法律的訴求。他們有權選擇他們分發具體自由軟件的對象;使用該權利并不違反 GPL,除非他們添加了 GPL 許可之外契約式限制。

我是否可以在一個用戶不繼續付費就不再工作的設備上使用GPL軟件?(#SubscriptionFee)

不行。在這種場景下,要求付費就是限制用戶用戶運行該程序。這是在 GPL 之上的額外要求,而 GPL 恰恰禁止這樣做。

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

首先,請在你的軟件包里加入新版的 GPL 許可證。如果你計劃使用 LGPLv3,那么確保你加入了 GPLv3 和 LGPLv3 這兩個許可證的拷貝,因為 LGPLv3 現在是作為 GPLv3 的額外許可撰寫的。

其次,把你現有的 v2 許可證聲明(通常在文件頭部)全部用位于 GNU 許可證須知 的新推薦文字替換。新的推薦文字更能適應將來的變化,因為它不再帶有 FSF 的郵寄地址。

當然,其他講述軟件許可證的描述性文字(比如 README)也應該做適當的更新。

GPLv3是怎樣讓BitTorrent發行變得更容易的?(#BitTorrent)

由于 GPLv2 是在點對點軟件發布成為通用模式之前寫成的,所以用這種方式分享代碼時很難滿足它的要求。在 BitTorrent 發布符合 GPLv2 的目標代碼的最佳方式是在同一個 torrent 上包含所有的相關源代碼,這個就貴的離譜了。

GPLv3 有兩個方法解決此問題。第一,下載此 torrent 并在此過程中將數據發送給第三方的人不會被要求做任何事。這是因為第 9 節說 “只是因為點對點傳輸而接收軟件拷貝等輔助的軟件傳播活動不必接受 [本許可證]。”

第二,GPLv3 的第 6(e) 節為——torrent 的原始種子發起者——設計了一個清晰而直接的方法來提供源代碼,這就是告訴接受方源代碼在公共網絡服務器的哪個地方可以得到。這就讓所有想得到源代碼的人可以得到,而對分發者幾乎沒有麻煩。

tivoization指的是什么?GPLv3如何禁止它?(#Tivoization)

有些設備使用可以升級的自由軟件,但是它們采用了一種不允許用戶修改軟件的設計。有很多方法可以做的這一點;比如,有時硬件會檢查已安裝軟件的校驗和,并在匹配錯誤時關機。這些制造商遵循 GPLv2 給了你源代碼,但是你還是沒有修改這個軟件的自由。我們稱之為 tivoization。

當人們分發包含遵循 GPLv3 軟件的最終用戶產品時,GPLv3 的第 6 節要求他們提供修改此軟件的信息。最終用戶產品是該許可證定義的一個專門術語;最終用戶產品包括便攜式音樂播放器、數字式錄像機以及家用安全系統等。

GPLv3禁止DRM嗎?(#DRMProhibited)

不;你可以使用按照 GPLv3 發布的軟件來開發 DRM 技術。不過,如果你這么做,那么按照第 3 節所述,你的系統不再被當作是一個有效的技術 “保護” 手段,這意味著如果有人破解了 DRM,那么她也有權利分發她的軟件,而不受 DMCA 和其他類似法律的妨礙。

和往常一樣,GNU GPL 并不限制人們用軟件做事,它只是阻止人們限制其他人。

能否用GPL作為硬件許可證?(#GPLHardware)

任何有版權的素材都能夠使用 GPL 來授權。GPLv3 還能夠為涉及其他版權法律的素材授權,比如半導體光掩模。因此,你可以按照 GPL 條款來發布一款物品的構圖或線路板。

很多時候,版權并不覆蓋到從構圖制作物理硬件。此時,你關于構圖的許可證就是不能發揮對制造或銷售物理硬件的控制,無論你使用什么許可證。當版權覆蓋到硬件制造時,比如集成電路光掩模,GPL 就能夠發揮作用。

我使用公鑰簽署我的代碼以保證其真實性。GPLv3會強制我公開私鑰,是這樣嗎?(#GiveUpKeys)

不。只有一種情況你需要發布簽名密鑰,這就是如果你把 GPL 軟件傳輸到一個用戶最終產品,而該產品的硬件在正常工作之前會驗證簽名密鑰。這是一個特殊的情況,你需要為每個擁有此設備的人按需提供簽名密鑰來驗證和安裝修改版軟件,這樣該設備才能運行修改版軟件。如果每個設備使用不同的密鑰,那么你只需為每個設備購買者提供一個密鑰。

GPLv3是否要求投票人可以修改投票機運行的軟件?(#v3VotingMachine)

不。發布包含著 GPLv3 軟件的設備的公司最多是被要求向擁有目標代碼的人提供源代碼和安裝信息。投票人并不擁有投票機(就像其他售賣機),連臨時擁有都不算,所以投票人沒有機器上二進制軟件的所有權。

不過,請注意,投票是一個非常特殊的例子。僅僅是因為計算機運行著自由軟件并不意味著你就應該相信此投票計算機。我們認為不能相信投票機。投票應該使用紙質系統。

GPLv3有沒有一個“專利報復條款”?(#v3PatentRetaliation)

實際上是有的。其第 10 節禁止傳輸軟件的人發起針對其他許可證的專利訴訟。如果有人這么做了,那么第 8 節解釋了他們這樣做會失去許可證以及任何相關專利的許可證。

我是否可以在和GPL不兼容的文檔里使用GPL軟件源代碼的片段?(#SourceCodeInDocumentation)

如果所用的代碼片段很小,那么你可以按照公平使用或相似的法律來使用。否則,你不能使用。

GPLv3的第6節說我可以“按照第4節和第5節的條款”輸送GPL協議程序的目標代碼,前提是我同時也滿足了第6節的要求。這究竟是什么意思?(#v3Under4and5)

這是說你輸送源代碼的所有授權和條件同樣適用于輸送目標代碼:你可以收費,你不能改變版權聲明,等等。

我的公司擁有很多專利。多年以來,我們按照“GPL版本2或以后版”貢獻了許多代碼,而這些代碼所屬的項目也是按照同樣的條款發布的。如果用戶決定按照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 節具體地賦予你添加自己的免責聲明的權利。

我的程序帶有天然不可見的用戶交互界面。我該如何遵守GPLv3要求的適當的法律聲明?(#NonvisualLegalNotices)

你需要保證用戶在你的界面上可以訪問到 GPLv3 所要求的適當法律聲明。例如,如果你寫的是有聲界面,那么你可以設計一個朗讀聲明的命令。

如果我把一份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 代碼組合在一起,因為根據 GPLv3 的第 7 節,AGPL 的額外要求應該被界定為是 “額外的限制”。這段文字就澄清了我們的解釋,而你可以把以上兩種許可證的代碼組合在一起。

這段文字僅用來解決許可證的矛盾之處。當兩個條款沒有矛盾之時,兩個條款必須同時滿足。該文字沒有授予你忽略許可證其他部分的權利——反之,它只是隔離出了很有限的例外情況。

根據AGPLv3,當我修改一個符合第13節的軟件時,該軟件必須提供哪些相關的源代碼?(#AGPLv3CorrespondingSource)

許可證的第 1 節定義了“相關的源代碼”,你應該按照所列的要求提供源代碼。因此,如果你的修改版的依賴庫使用了其他的許可證,比如 Expat 或 GPLv3,那么相關的源代碼應當包含這些依賴庫(除非它們是系統庫)。如果你修改了這些庫,那么你必須提供修改后的源代碼。

第 13 節第一段的最后一句話只是用來強調大多數人本來就接受的假定:即使組合 GPLv3 代碼是由第 13 節的特殊例外來處理的,組合程序也仍然要按照要求包含相關源代碼。這句話不是說你 需提供 GPLv3 代碼;反之,它是說 GPLv3 代碼 沒有 被排除在相關代碼的定義之外。

在AGPLv3中,什么應該算作是“通過計算機網絡和[該軟件]遠程交互?”(#AGPLv3InteractingRemotely)

如果程序的設計明顯是通過網絡接受用戶請求和發送回復,那么該程序就符合遠程交互的判定條件。符合此類條件的常見程序包括網絡服務器和郵件服務器、交互式網絡應用程序以及在線游戲的服務器。

如果程序的設計不是明顯地通過網絡來和用戶交互,但是該程序碰巧運行在一個需要網絡交互的環境下,那么它不算是遠程交互程序。例如,用戶使用 SSH 或遠程 X 會話運行了某個應用。

GPLv3中“你”的概念和Apache許可證2.0中“法律主體”有何異同?(#ApacheLegalEntity)

它們實際上是等效的。Apache 許可證 2.0 版的“法律主體”的定義在各種法律協議中是非常標準的——如果有法庭做出了不同的解釋,那就非常地意外了。我們完全相信法庭看到 GPLv3 和判斷誰是許可證被授權者時會做出一致的解釋。

在GPLv3中,“程序”指的是什么?是不是指所有按照GPLv3發布的程序?(#v3TheProgram)

“程序” 是指使用 GPLv3 許可證授權的具體作品,該作品由授權方或發布方發布給具體的許可證接收方。接收時,程序就是一個按照具體 GPLv3 許可證發布的具體軟件。

“程序”不是指“所有按照 GPLv3 發布的作品”;這種解讀沒有道理。為了更好地理解這個道理,我們發布了 關于 “程序” 這一術語的分析

如果我只是復制并運行GPL程序,并不向他人分發或輸送,那么該許可證對我有什么要求?(#NoDistributionRequirements)

什么也沒有。GPL 對此沒有任何約束。

如果一個網絡客戶端程序按照AGPLv3發布,那么它是否必須能夠向其交互的服務器提供源代碼?(#AGPLv3ServerAsUser)

AGPLv3 要求軟件向 “所有與其通過網絡進行遠程交互的用戶” 提供源代碼。該程序被叫做 “客戶端” 還是 “服務器” 并不重要,你需要問的問題是你是否期待人們通過網絡遠程和該程序交互。

對于運行代理服務器的AGPL軟件,我們怎樣才能為和這些程序交互的用戶提供源代碼?(#AGPLProxy)

對于代理服務器上的軟件,你可以通過向代理服務器用戶正常發送消息的方法為他們提供源代碼。例如,網絡代理可以使用起始頁面。當用戶開始使用代理時,你可以把他們引導到提供源代碼等信息的頁面。

AGPL 規定你必須為 “所有用戶” 提供源代碼。如果你知道某些用戶已經獲得了目前版本的源代碼,那么你就無需為這些用戶再重復此事。

各種GNU許可證如何彼此兼容?(#AllCompatibility)

各種 GNU 許可證互相之間友好兼容。你唯一可能碰到的無法組合源代碼的情況是一個程序 使用了老的許可證而另一個程序使用了新的許可證。

下面是各種 GNU 許可證組合的兼容性的詳細列表,它可以作為一個具體案例的快速參考。假定有一個軟件使用了其中一個許可證,而你想把它的代碼組合到你要發布的項目中(無論是你自己的原創,還是你對其他軟件的修改版)。在表格的第一行找到你的項目要用的許可證,然后在左邊第一列找到你要組合的軟件的許可證。這一行一列的交叉表格就是你是否可以組合兩個軟件的答案。

當我們說 “復制代碼,” 時,我們是指:你從一個軟件取了一部分代碼,改或不改都行,然后把它添加到你的程序中構成一個作品。“使用庫” 是指:你沒有直接復制源代碼,而是在編譯或運行時通過連接、導入或其他典型的機制把軟件綁定在一起。

表格中有 GPLv3 的地方, 其兼容性的陳述對 AGPLv3 也適用。

跳過兼容性表格


我要使用許可證:
GPLv2 GPLv2 或者其以后版 GPLv3 或者其以后版 LGPLv2.1 LGPLv2.1 或者其以后版 LGPLv3 或者其以后版
我要復制的代碼使用許可證: GPLv2 可以 可以 [2] 不行 可以:組合只遵循 GPLv2 [7] 可以:組合只遵循 GPLv2 [7][2] 不行
GPLv2 或者其以后版 可以 [1] 可以 可以 可以:組合遵循 GPLv2 或者其以后版 [7] 可以:組合遵循 GPLv2 或者其以后版 [7] 可以:組合遵循 GPLv3 [8]
GPLv3 不行 可以:組合遵循 GPLv3 [3] 可以 可以:組合遵循 GPLv3 [7] 可以:組合遵循 GPLv3 [7] 可以:組合遵循 GPLv3 [8]
LGPLv2.1 可以:按照 GPLv2 輸送復制的代碼 [7] 可以:按照 GPLv2 或者其以后版輸送復制的代碼 [7] 可以:按照 GPLv3 或者其以后版輸送復制的代碼 [7] 可以 可以 [6] 可以:按照 GPLv3 輸送復制的代碼 [7][8]
LGPLv2.1 或者其以后版 可以:按照 GPLv2 輸送復制的代碼 [7][1] 可以:按照 GPLv2 或者其以后版輸送復制的代碼 [7] 可以:按照 GPLv3 或者其以后版輸送復制的代碼 [7] 可以 [5] 可以 可以
LGPLv3 不行 可以:組合遵循 GPLv3 [8][3] 可以:組合遵循 GPLv3 [8] 可以:組合遵循 GPLv3 [7][8] 可以:組合遵循 LGPLv3 [4] 可以:組合遵循 LGPLv3
我使用的庫遵循: GPLv2 可以 可以 [2] 不行 可以:組合只遵循 GPLv2 [7] 可以:組合只遵循 GPLv2 [7][2] 不行
GPLv2 或者其以后版 可以 [1] 可以 可以 可以:組合遵循 GPLv2 或者其以后版 [7] 可以:組合遵循 GPLv2 或者其以后版 [7] 可以:組合遵循 GPLv3 [8]
GPLv3 不行 可以:組合遵循 GPLv3 [3] 可以 可以:組合遵循 GPLv3 [7] 可以:組合遵循 GPLv3 [7] 可以:組合遵循 GPLv3 [8]
LGPLv2.1 可以 可以 可以 可以 可以 可以
LGPLv2.1 或者其以后版 可以 可以 可以 可以 可以 可以
LGPLv3 不行 可以:組合遵循 GPLv3 [9] 可以 可以 可以 可以

跳過腳注

1: 在這種情況下合并代碼時,你必須遵循 GPLv2 的條款。你不能利用 GPL 以后版的優勢。

2: 在這種情況下,你可以按照 GPLv2 或者其以后版發布你的項目(無論是原創還是改進),但是要注意你使用的其他代碼必須繼續只使用 GPLv2 許可證。只要你的項目還依賴于其他代碼,你就不能把你的項目許可證升級為 GPLv3 或者其以后版本,而整個作品(你的項目和其他代碼的組合)只能使用 GPLv2 來輸送。

3: 如果你能夠按照 GPLv2 或者其以后版本發布你的項目,那么你就可以選擇使用 GPLv3 或者其以后版本來發布——一旦你這樣做了,你就可以組合其他按照 GPLv3 發布的代碼。

4: 如果你能夠按照 GPLv2.1 或者其以后版本發布你的項目,那么你就可以選擇使用 GPLv3 或者其以后版本來發布——一旦你這樣做了,你就可以組合其他按照 GPLv3 發布的代碼。

5: 在這種情況下合并代碼時,你必須遵循 GPLv2.1 的條款。你不能利用 GPL 以后版的優勢。

6: 如果你這樣做了,那么只要項目的代碼包含只遵循 LGPLv2.1 的代碼,你就不能把該項目的許可證升級到 LGPLv3 或者其以后版本。

7: LGPLv2.1 允許你把代碼重新按照 GPLv2 以后的 GPL 許可證發布。此時,如果你可以把 LGPL 代碼按照合適的 GPL 發布(如表格所示),那么你就可以進行該組合。

8: LGPLv3 是 GPLv3 加上一些額外的許可,在這種情況下,你不用考慮這些額外的許可。

9: 由于 GPLv2 不允許和 LGPLv3 組合,所以此時你必須按照 GPLv3 的條款輸送項目的代碼,GPLv3 允許該組合。

最頂

[FSF 標志]“自由軟件基金會(FSF)是一個非盈利組織。我們的使命是在全球范圍內促進計算機用戶的自由。我們捍衛所有軟件用戶的權利。”

加入 購物

招财蟾蜍APP 通过微信群资源共享赚钱 比较火的网络赚钱项目 听歌可以赚钱 单开能赚钱的手机游戏 财务部门如何为企业赚钱的措施 做什么食品最好赚钱 如何在网上卖酒赚钱 汉正街卖布匹赚钱吗 怎么从网上赚钱有没有骗局 dnf打造垫子赚钱吗 做什么副业能赚钱 直播刷粉丝怎么赚钱 60魔兽打怪赚钱 直播的粉丝怎么赚钱吗 淘宝无货源怎么做赚钱吗好做 做什么生意好赚钱女性