各開源協議BSD,GPL,LGPL,Apache 2.0,mit等簡介＊

 

快速閱讀

分類	子分類	開源約定
BSD	original BSD license、FreeBSD license、Original BSD license	隨心所欲
Apache Licence 2.0	Apache License, Version 2.0、Apache License, Version 1.一、 Apache License, Version 1.0	該協議和BSD相似
GPL	GPL  V2 ，GPL V3	嚴，有傳染性，
LGPL	－	嚴，GPL的一個爲主要爲類庫使用設計的開源協議。
MIT	－	和BSD同樣寬範的許可協議,.

詳文

　　現今存在的開源協議不少，而通過Open Source Initiative組織經過批准的開源協議目前有幾十種（http://www.opensource.org/licenses /alphabetical）。咱們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。若是要開源本身的代碼，最好也是選擇這些被批准的開源協議。

　　這裏咱們來看四種最經常使用的開源協議及它們的適用範圍，供那些準備開源或者使用開源產品的開發人員/廠家參考。

BSD開源協議（original BSD license、FreeBSD license、Original BSD license）

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

   1. 若是再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
   2. 若是再發布的只是二進制類庫/軟件，則須要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
   3. 不能夠用開源代碼的做者/機構名字和原來產品的名字作市場推廣。

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

Apache Licence 2.0（Apache License, Version 2.0、Apache License, Version 1.一、Apache License, Version 1.0）

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

   1. 須要給代碼的用戶一份Apache Licence
   2. 若是你修改了代碼，須要再被修改的文件中說明。
   3. 在延伸的代碼中（修改和有源代碼衍生的代碼中）須要帶有原來代碼中的協議，商標，專利聲明和其餘原來做者規定須要包含的說明。
   4. 若是再發布的產品中包含一個Notice文件，則在Notice文件中須要帶有Apache Licence。你能夠在Notice中增長本身的許可，但不能夠表現爲對Apache Licence構成更改。

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

GPL（GNU General Public License）

　　咱們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不同。GPL的出發點是代碼的開源/無償使用和引用/修改/衍生代碼的開源/無償使用，但不容許修改後和衍生的代 碼作爲閉源的商業軟件發佈和銷售。這也就是爲何咱們能用免費的各類linux，包括商業公司的linux和linux上各類各樣的由我的，組織，以及商 業軟件公司開發的免費軟件了。

　　GPL協議的主要內容是隻要在一個軟件中使用(」使用」指類庫引用，修改後的代碼或者衍生代碼)GPL 協議的產品，則該軟件產品必須也採用GPL協議，既必須也是開源和免費。這就是所謂的」傳染性」。GPL協議的產品做爲一個單獨的產品使用沒有任何問題， 還能夠享受免費的優點。

　　因爲GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟件或者對代碼有保密要求的部門就不適合集成/採用做爲類庫和二次開發的基礎。

　　其它細節如再發布的時候須要伴隨GPL協議等和BSD/Apache等相似。

關於開源協議GPL　V2和V3

　　單從開源行業的GPL協議上來看，彷佛開源linux產品上的一切是能夠無條件的開放和共享的，可是從實際的操做來看，在GPL相對的許可受權之下，又有其相對封閉的一面，就此次的GPL v2到GPL v3的修訂改版來講，正是GPL協議「封閉」一面的具體體現。

　　根據GPL v2的相關規定：只要這種修改文本在總體上或者其某個部分來源於遵循GPL的程序，該修改文本的總體就必須按照GPL流通，不只該修改文本的源碼必須向社 會公開，並且對於這種修改文本的流通不許許附加修改者本身做出的限制。而在GPL v3的修訂草案中，不只要求用戶公佈修改的源代碼，還要求公佈相關硬件，偏偏是這一條，因爲觸及和其餘相關數字版權管理(DRM)及其產品的關係，而且也 因爲有和開源精神相違的地方，因此備受爭議，甚至所以也遭到了有着「LINUX之父」之稱的託瓦爾茲的反對。

　　從表面上看，GPL v2到GPL v3的升級之困只不過是對協議修訂過程當中某一條款的分歧，而更爲嚴重的是在兩種協議都合法存在的前提下，具體的開源軟件或者開源產品的全部者有權選擇是遵 循GPL v2協議仍是恪守GPL v3協議，所以衝突也就來了，這種衝突正如中科紅旗的CTO鄭忠源描述的那樣：「世界有如此多軟件都在GPL v2的約束之下，而自由軟件是集合全世界程序員勞動，即便是貢獻一行代碼，若是該程序員只贊成這一代碼只遵循GPL v2之下，就不能隨便去修改協議。若是計劃將軟件轉移到GPL v3之下，理論上講，必須徵得全部代碼人的贊成。可是目前還很難肯定有多少開發人員願意轉移到新版本之下，若是有的人願意轉，有的人不肯意轉，這其中就有 不少的麻煩；而若是多數人都不肯意改變，那這一事情也許就無聲無息……」

　　經過業內人士的精闢描述，相信你們必定對開源行業和開源軟件產品有了一個全新的認識吧，就那熟悉的LINUX系統來講，雖然表面上看起來你們有權按 照本身的須要和目的進行任意的改寫重組，可是在諸多的獨立程序面前，別人是隻能共享使用，而無權修改的，固然得到受權就另當別論了。而就GPL v2到GPL v3的協議升級來講，這種協議的選擇上的分歧實際上也是開源行業裏一種觀念認知上的相左，到底誰的選擇是正確的？絕對不是一兩句話能說得清的，尤爲是在各 種利益交織之下。

情勢之下，開源社區的GPL v2與GPL v3選擇之困很現實的會在至關一段時間內給這個行業及其產品形成「兼容問題」，說白了就是兩種協議以及兩種協議之下的矛盾，不論是人的仍是產品的都將會持 續下去，而這種僵持對整個開源行業來講未必是一件好事，最起碼從「精神」方面來講這個行業已經在開始分道揚鑣。

LGPL（GNU Lesser General Public License）

　　LGPL是GPL的一個爲主要爲類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須採用GPL協議不一樣。 LGPL 容許商業軟件經過類庫引用(link)方式使用LGPL類庫而不須要開源商業軟件的代碼。這使得采用LGPL協議的開源代碼能夠被商業軟件做爲類庫引用併發布和銷售。

　　可是若是修改LGPL協議的代碼或者衍生，則全部修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。所以LGPL協議的開源 代碼很適合做爲第三方類庫被商業軟件引用，但不適合但願以LGPL協議代碼爲基礎，經過修改和衍生的方式作二次開發的商業軟件採用。

　　GPL/LGPL都保障原做者的知識產權，避免有人利用開源代碼複製並開發相似的產品

MIT（MIT）

　　MIT是和BSD同樣寬範的許可協議,做者只想保留版權,而無任何其餘了限制.也就是說,你必須在你的發行版裏包含原許可協議的聲明,不管你是以二進制發佈的仍是以源代碼發佈的.