軟件許可證——GPL、AGPL、LGPL、Apache、ZLIB/LIBPNG、MIT

 

[-]網絡

    1. GPL 協議ui

    2. AGPL 協議google

  1. GPL的約束生效的前提是發佈軟件即便用了GPL成分的軟件經過互聯網或光盤release軟件就必需明示地附上源代碼而且源代碼和產品也受GPL保護spa

  2. 這樣若是不發佈就能夠不受約束了好比使用GPL組件編寫一個Web系統不發佈這個系統可是用這個系統在線提供服務同時不開源系統代碼.net

    1. LGPL 協議開放源代碼

    2. Apache 協議rest

    3. ZlibLibpng協議code

    4. BSD 協議orm

    5. MIT 協議blog

GPL 協議

即通用性公開許可證(General Public License,簡稱GPL)。

GPL同其它的自由軟件許可證同樣,許可社會公衆享有:運行、複製軟件的自由,發行傳播軟件的自由,得到軟件源碼的自由,改進軟件並將本身做出的改進版本向社會發行傳播的自由。 


GPL還規定:只要這種修改文本在總體上或者其某個部分來源於遵循GPL的程序,該修改文本的 總體就必須按照GPL流通,不只該修改文本的源碼必須向社會公開,並且對於這種修改文本的流通不許許附加修改者本身做出的限制。所以,一項遵循GPL流通 的程序不能同非自由的軟件合併。GPL所表達的這種流通規則稱爲copyleft,表示與copyright(版權)的概念「相左」。

GPL協議最主要的幾個原則:

一、確保軟件自始至終都以開放源代碼形式發佈,保護開發成果不被竊取用做商業發售。任何一套軟 件,只要其中使用了受 GPL 協議保護的第三方軟件的源程序,並向非開發人員發佈時,軟件自己也就自動成爲受 GPL 保護而且約束的實體。也就是說,此時它必須開放源代碼。

二、GPL 大體就是一個左側版權(Copyleft,或譯爲「反版權」、「版權屬左」、「版權所無」、「版責」等)的體現。你能夠去掉全部原做的版權 信息,只要你保持開源,而且隨源代碼、二進制版附上 GPL 的許可證就行,讓後人能夠很明確地得知此軟件的受權信息。GPL 精髓就是,只要使軟件在完整開源 的狀況下,儘量使使用者獲得自由發揮的空間,使軟件獲得更快更好的發展。

三、不管軟件以何種形式發佈,都必須同時附上源代碼。例如在 Web 上提供下載,就必須在二進制版本(若是有的話)下載的同一個頁面,清楚地提供源代碼下載的連接。若是以光盤形式發佈,就必須同時附上源文件的光盤。

四、開發或維護遵循 GPL 協議開發的軟件的公司或我的,能夠對使用者收取必定的服務費用。但仍是一句老話——必須無償提供軟件的完整源代碼,不得將源代碼與服務作捆綁或任何變相捆綁銷售。


GPL詳細信息


AGPL 協議:

原有的GPL協議,因爲如今網絡服務公司興起(如:google)產生了必定的漏洞,好比使用GPL的自由軟件,可是並不發佈與網絡之中,則能夠自由的使 用GPL協議確不開源本身私有的解決方案。AGPL則增長了對此作法的約束。


GPL的約束生效的前提是「發佈」軟件,即便用了GPL成分的軟件經過互聯網或光盤release軟件,就必需明示地附上源代碼,而且源代碼和產品也受GPL保護。


這樣若是不「發佈」就能夠不受約束了。好比使用GPL組件編寫一個Web系統,不發佈這個系統,可是用這個系統在線提供服務,同時不開源系統代碼。

AGPL詳細信息


LGPL 協議:

寬鬆公共許可證(Lesser General Public License)或庫通用公共許可證(Library General Public License)


基於 LGPL 的軟件也容許商業化銷售,但不容許封閉源代碼。
若是您對遵循 LGPL 的軟件進行任何改動和/或再次開發並予以發佈,則您的產品必須繼承 LGPL 協議,不容許封閉源代碼。可是若是您的程序對遵循 LGPL 的軟件進行任何鏈接、調用而不是包含,則容許封閉源代碼。


LGPL詳細信息


Apache 協議:

Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD相似,一樣鼓勵代碼共享和尊重原做者的著做權,一樣容許代碼修改,再發布(做爲開源或商業軟件)。須要知足的條件也和BSD相似:

  1. 須要給代碼的用戶一份Apache Licence

  2. 若是你修改了代碼,須要在被修改的文件中說明。

  3. 在延伸的代碼中(修改和有源代碼衍生的代碼中)須要帶有原來代碼中的協議,商標,專利聲明和其餘原來做者規定須要包含的說明。

  4. 若是再發布的產品中包含一個Notice文件,則在Notice文件中須要帶有Apache Licence。你能夠在Notice中增長本身的許可,但不能夠表現爲對Apache Licence構成更改。

Apache Licence也是對商業應用友好的許可。使用者也能夠在須要的時候修改代碼來知足須要並做爲開源或商業產品發佈/銷售。


http://en.wikipedia.org/wiki/Apache_License


Zlib/Libpng協議:

The license only has the following points to be accounted for:
Software is used on 'as-is' basis. Authors are not liable for any damages arising from its use.


The distribution of a modified version of the software is subject to the following restrictions:
   1.The authorship of the original software must not be misrepresented,
   2.Altered source versions must not be misrepresented as being the original software, and
   3.The license notice must not be removed from source distributions.
The license does not require source code to be made available if distributing binary code.


中文參考以下(我的理解)

該協議要求遵照如下幾點:

基於該軟件的原樣使用,做者不負責使用該軟件照成的任何損失。

該軟件修改後的版本將受到如下限制:

  1. 不能歪曲原軟件的著做權

  2. 修改後的軟件不能歪曲爲原版軟件

  3. 不能刪除源碼中的協議許可內容

若是發佈二進制代碼能夠不用附上源代碼。


http://en.wikipedia.org/wiki/Zlib_License


BSD 協議:

BSD開源協議是一個給於使用者很大自由的協議。能夠自由的使用,修改源代碼,也能夠將修改後的代碼做爲開源或者專有軟件再發布。當你發佈使用了BSD協議的代碼,或者以BSD協議代碼爲基礎作二次開發本身的產品時,須要知足三個條件:

  1. 若是再發布的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。

  2. 若是再發布的只是二進制類庫/軟件,則須要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。

  3. 不能夠用開源代碼的做者/機構名字和原來產品的名字作市場推廣。

BSD代碼鼓勵代碼共享,但須要尊重代碼做者的著做權。BSD因爲容許使用者修改和從新發布代碼,也容許使用或在BSD代碼上開發商業軟件發佈和銷 售,所以是對商業集成很友好的協議。不少的公司企業在選用開源產品的時候都首選BSD協議,由於能夠徹底控制這些第三方的代碼,在必要的時候能夠修改或者 二次開發。


http://zh.wikipedia.org/wiki/BSD%E8%AE%B8%E5%8F%AF%E8%AF%81


MIT 協議:

MIT許可證之名源自麻省理工學院(Massachusetts Institute of Technology, MIT),又稱「X條款」(X License)或「X11條款」(X11 License),MIT內容與三條款BSD許可證(3-clause BSD license)內容頗爲近似,可是賦予軟體被受權人更大的權利與更少的限制。

  1. 被受權人有權利使用、複製、修改、合併、出版發行、散佈、再受權及販售軟體及軟體的副本。

  2. 被受權人可根據程式的須要修改受權條款爲適當的內容。

  3. 在軟件和軟件的全部副本中都必須包含版權聲明和許可聲明。

此受權條款並不是屬copyleft的自由軟體受權條款,容許在自由/開放源碼軟體或非自由軟體(proprietary software)所使用。此亦爲MIT與BSD(The BSD license, 3-clause BSD license)本質上不一樣處。MIT條款可與其餘受權條款並存。另外,MIT條款也是自由軟體基金會(FSF)所承認的自由軟體受權條款,與GPL相容。


http://en.wikipedia.org/wiki/MIT_License

相關文章
相關標籤/搜索