瞭解常見的開源協議(BSD, GPL, LGPL,MIT)

時間 2019-11-09

標籤瞭解常見的開源協議 bsd gpl lgpl mit 简体版

原文原文鏈接

一直對各類開源協議比較模糊, 特地在網上搜索了一下資料, 整理總結,以做記錄linux

若是不喜歡長篇大論的話, 看下圖就能夠了併發

基本概念瞭解:函數

1. Contributors 和 Recipients

　　Contributors 指的是對某個開源軟件或項目提供了代碼(包括最初的或者修改過的)發佈的人或者實體(團隊、公司、組織等),Contributors 按照參與某個軟件開源的時間前後,能夠分爲 an initial Contributor 和 subsequent Contributors .

　　Recipients指的是開源軟件或項目的獲取者,顯然,subsequent Contributors 也屬於 Recipients之列.

2. Source Code 和 Object Code

　　Source Code 指的是各類語言寫成的源代碼,經過Source Code,結合文檔, 能夠了解到整個軟件的體系結構及具體到某個功能函數的實現方法等.

　　Object Code 指的是Source Code 通過編譯以後,生成的相似於「類庫」同樣的,提供各類接口供他人使用的目標碼,按個人理解,它就是像常見的DLL、ActiveX、OCX控件性質的東西.(不知道這樣理解對不對)

　　分清楚這兩個概念的目的在於,有些開源,只發布Object Code ,固然,大多數發佈的是Source Code.不少協議也對「你發佈的是哪一種Code的時候應該怎樣」,有着明確的約束.

3. Derivative Module 和 Separate Module

　　Derivative Module 指的是,依託或包含「最初的」或者「從別人處獲取的」開源代碼而產生的代碼,是原「源代碼」的加強(不等於增長)、改善和延續的模塊,意爲「衍生模塊」.

　　Separate Module 指的是,參考或藉助原「源代碼」,開發出的獨立的,不包含、不依賴於原「源代碼模塊」,意爲「獨立的模塊」.理解這兩個概念的目的在於,不少協議對涉及到商業發佈的時候,會有哪些是衍生的,哪些是獨立的,有着明確的商業發佈規定.

　　現今存在的開源協議不少,而通過Open Source Initiative組織經過批准的開源協議目前有58種.咱們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議.若是要開源本身的代碼,最好也是選擇這些被批准的開源協議.
　　這裏咱們來看四種最經常使用的開源協議及它們的適用範圍,供那些準備開源或者使用開源產品的開發人員/廠家參考.spa

BSD開源協議(Berkeley Software Distribution )

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

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

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

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

　　其實這幾個規則約定的目的也只是達到一個目的:是他人的東西,別人以BSD開源了,你就不能不作任何聲明而佔爲己有,更不能用他人的名義來作商業推廣.你只對你本身的東西擁有絕對控制權.

　　舉個例子,你用開源代碼(A)修改或作其餘增添以後,產生了產品B,這時候,你對B的控制由你本身決定,你能夠用任何協議再開源,也能夠閉源商業發佈.但,由於若是B中包含了A或A的一部分(一點都不包含就不叫修改了),那你在B產品的版權聲明中,必須有提到你有使用到 A ,而且附帶上 A 的開源協議.並且不能作商業推廣的時候將B 冠以原開源做者的名義以促進商業推廣.

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

Apache Licence 2.0

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

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

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

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

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

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

GPL (Gun General Public License)vesion 2.0 1991

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

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

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

　　最多見的開源協議,使用它做爲受權協議的有大名鼎鼎的 Linux .GPL最顯著的兩個特色就是網上稱爲的「病毒性傳播」和「不容許閉源的商業發佈」.

　　所謂的「病毒性傳播」,指的是,GPL規定,全部從GPL協議受權的源碼衍生出來的(即上面提到的Derivative Module),或者要跟GPL受權的源碼混着用的Project,都要遵循GPL協議,就像病毒同樣,粘上了關係,就「中毒」了.GPL這樣規定的目的是,保證在GPL協議保護下的產品,不會再受到其餘協議或者受權的約束.即讓跟GPL有關係的源碼都能免費獲取.舉個例子,若是你的改進的Linux中使用了GPL受權下的開源模塊(也必須使用,你不可能本身從新去作個內核吧,若是作出來了,你也不必叫Linux了.),那麼你整個Linux產品也必須遵循GPL協議去開源,不能以其餘方式去開源發佈,更不容許閉源發佈.這樣一來,就不會出現這樣一個Linux--這個功能是GPL協議受權的,能夠免費獲取源碼,而另一個功能是其餘協議下的,拿不到源碼.這點規定對使用或者研究該產品的人來講,是一個極大的便利.

　　而「不容許閉源商業發佈」指的是,在GPL受權下,你的軟件產品能夠商業發佈,拿去賣錢,可是在這同時,你也必須將該產品的源碼以GPL協議方式開源發佈出去,供他人免費獲取.也許有人會迷惑,拿去賣,又同時開源,那誰來買阿?這個產品怎麼賺錢呢??這就涉及到開源產品的商業模式的問題了,想了解相關一些信息的話,能夠看看以上我給出連接的一些文章.至於後面,可能會寫一篇關於開源項目的商業模式的隨筆.

　　GPL協議下的商業發佈的一個關鍵點就像 Java 視線論壇的 Robbin所說的,GPL是針對軟件源代碼的版權,而不是針對軟件編譯後二進制版本的版權.你有權免費得到軟件的源代碼,可是你沒有權力免費得到軟件的二進制發行版本.GP對軟件發行版本惟一的限制就是:你的發行版本必須把完整的源代碼一同提供.

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

LGPL

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

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

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

CPL(Common Public Liecense) vesion 1.0

　　CPL是IBM 提出的並經過了OSI(Open Source Initiative)批准的開源協議.主要用於一些IBM或跟IBM相關的開源軟件/項目中.如很著名的Java開發環境 Eclipse 、RIA開發平臺Open Laszlo等.

　　CPL也是一項對商業應用友好的協議.它容許 Recipients 對源碼進行任意的使用、複製、分發、傳播、展現、修改以及改後作閉源的二次商業發佈,這點跟 BSD 很相似,也屬於自由度比較高的開源協議.可是,須要遵循:

　　1. 當一個Contributors將源碼的總體或部分再次開源發佈的時候,必須繼續遵循 CPL開源協議來發布,而不能改用其餘協議發佈.除非你獲得了原「源碼」Owner 的受權.

　　2. CPL協議下,你能夠將源碼不作任何修改來商業發佈.但若是你要將修改後的源碼其開源,並且當你再發布的是Object Code的時候,你必須聲明它的Source Code 是能夠獲取的,並且要告知獲取方法.

　　3. 當你須要將CPL下的源碼做爲一部分跟其餘私有的源碼混和着成爲一個 Project 發佈的時候,你能夠將整個Project/Product 以私人的協議發佈,但要聲明哪一部分代碼是CPL下的,並且聲明那部分代碼繼續遵循CPL.

　　4. 獨立的模塊(Separate Module),不須要開源.設計