重要開源協議的比較(BSD,Apache,GPL,LGPL,MIT) – 整理

當Adobe、Microsoft、Sun等一系列巨頭開始表現出對”開源”的青睞時,”開源”的時代即將到來!


最初來自:sinoprise.com/read.php?tid-662-page-e-fpage-1.html(遺憾的是這個鏈接已經打不開了),我基本未改動,只是進行了一些排版和整理。

參考文獻:http://www.fsf.org/licensing/licenses/


現今存在的開源協議很多,而經過Open Source Initiative組織通過批准的開源協議目前有58種(http://www.opensource.org/licenses/alphabetical)。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。如果要開源自己的代碼,最好也是選擇這些被批准的開源協議。


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


BSD開源協議(original BSD license、FreeBSD license、Original BSD license)


BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”爲所欲爲”,可以自由的使用,修改源代碼,也可以將修改後的代碼作爲開源或者專有軟件再發布。


但”爲所欲爲”的前提當你發佈使用了BSD協議的代碼,或則以BSD協議代碼爲基礎做二次開發自己的產品時,需要滿足三個條件:


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

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

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

BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟件發佈和銷售,因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因爲可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。


Apache Licence 2.0(Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0)


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


需要給代碼的用戶一份Apache Licence

如果你修改了代碼,需要再被修改的文件中說明。

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

如果再發布的產品中包含一個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等類似。


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一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裏包含原許可協議的聲明,無論你是以二進制發佈的還是以源代碼發佈的.


————————————————————————————————————————————————————————————————————————————————————————————


關於開源許可

現今存在的開源協議很多,而經過Open Source Initiative 組織通過批准的開源協議目前有60多種(http://www.opensource.org/licenses/alphabetical )。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。


基本概念

1.Contributors 和 Recipients

Contributors(貢獻者) ——指的是對某個開源軟件或項目提供了代碼(包括最初的或者修改過)的人或實體(退隊、公司、組織等)。

按照貢獻的先後可分爲"創始人"(an initial Contributor)和"參與者"(subsequent Contributors)。

Recipients(獲取者) ——指的是開源軟件或項目的使用者。

顯然,subsequent Contributors也屬於Recipients之列。

2.Source Code 和 Object Code

Source Code ——指的是由各種語言寫成的源代碼 。

Object Code ——指的是Source Code經過編譯後,生成的類似“類庫”一樣的,提供了各種接口供他人使用的目標代碼 (就如,DLL、JAR等)。

3.Derivative Module 和 Separate Module

Derivative Module(衍生模塊) ——指的是,依託或包含“最初的”或者“從別人處獲取的”開源代碼而產生的代碼,是對“源代碼模塊”的增強、改善和延續。

Separate Module(獨立模塊) ——指的是,參考或藉助“源代碼”開發出來的獨立的,不包含、不依賴於原“源代碼模塊”的功能模塊。

在OSI網站上被列爲主流及被廣泛使用的許可 有:

*Apache License, 2.0 (Apache-2.0)

*BSD 3-Clause "New" or "Revised" license (BSD-3-Clause)

*BSD 3-Clause "Simplified" or "FreeBSD" license (BSD-2-Clause)

*GNU General Public License (GPL)

*GNU Library or "Lesser" General Public License (LGPL)

*MIT license (MIT)

*Mozilla Public License 1.1 (MPL-1.1)

*Common Development and Distribution License (CDDL-1.0)

*Eclipse Public License (EPL-1.0)

注:原Common Public License 1.0已被Eclipse Public License (EPL-1.0)替代。

Apache License, 2.0 (Apache-2.0 )

Apache Lience允許使用者修改和重新發布代碼(以其他協議形式),允許閉源商業發佈和銷售。

Apache Lience鼓勵代碼共享和尊重原作者的著作權。


使用Apache Licence協議,需要遵守以下規則:

1.需要給代碼的用戶一份Apache Lience;

2.如果你修改了代碼,需要在被修改的文件中說明;

3.在延伸的代碼中(修改或衍生的代碼)需要帶有原來代碼中的協議、商標、專利聲明和其他原來作者規定需要包含的說明。

4.如果再發布的產品中包含了Notice文件,則需要在Notice文件中帶有Apache Lience。你可以在Notice中增加自己的許可,但不可以表現爲對Apache Lience構成更改。

* Apache Licence是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作爲開源或商業產品發佈/銷售。

BSD開源協議(Berkerley Software Distribution)( BSD 3-Clause , BSD 2-Clause )

目前分爲BSD 3-Clause和BSD 2-Clause。顧名思義,3-Clause包含3個條款,2-Clause只有兩個。


BSD允許使用者修改和重新發布代碼(以其他協議形式),允許閉源商業發佈和銷售。


BSD鼓勵代碼共享的同時,要求尊重代碼作者的著作權。


使用BSD協議,需要遵守以下規則(2-Clause則不帶第3條):

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

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

3.不可以用開源代碼的“作者/機構的名字”或“原來產品的名字”做市場推廣。

要點:商業軟件可以使用,也可以修改使用BSD協議的代碼。

GPL ( GNU General Public License )

GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代碼做爲閉源的商業軟件發佈和銷售。

GPL具有“傳染性”,只要在一個軟件中使用(“使用”指類庫引用,修改後的代碼或者衍生代碼)GPL協議的產品,則該軟件產品必須也採用 GPL協議,既必須也是開源和免費。

GPL對商業發佈的限制(引自Java視線論壇的Robbin):

“GPL是針對軟件源代碼的版權,而不是針對軟件編譯後二進制版本的版權.你有權免費獲得軟件的源代碼,但是你沒有權力免費獲得軟件的二進制發行版本.GP對軟件發行版本唯一的限制就是:你的發行版本必須把完整的源代碼一同提供.”

使用GPL協議,需要遵守以下規則:

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

2、GPL 大致就是一個左側版權(Copyleft,或譯爲“反版權”、“版權屬左”、“版權所無”、“版責”等)的體現。你可以去掉所有原作的版權 信息,只要你保持開源,並且隨源代碼、二進制版附上 GPL 的許可證就行,讓後人可以很明確地得知此軟件的授權信息。GPL 精髓就是,只要使軟件在完整開源 的情況下,儘可能使使用者得到自由發揮的空間,使軟件得到更快更好的發展。

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

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

由於GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議,所以商業軟件就不適合採用使用GPL協議的開源代碼。

要點:商業軟件不能使用GPL協議的代碼。

LGPL ( GNU Library or "Lesser" General Public License )

與GPL的強制性開源不同的是,LGPL允許商業軟件通過類庫引用(link)的方式使用LGPL類庫而不需要開源商業軟件的代碼。

但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很適合作爲第三方類庫被商業軟件引用,但不適合希望以LGPL協議代碼爲基礎,通過修改和衍生的方式做二次開發的商業軟件採用。


要點:商業軟件可以使用,但不能修改LGPL協議的代碼。


MIT ( MIT license )

[MIT許可證之名源自麻省理工學院(Massachusetts Institute of Technology, MIT),又稱「X條款」(X License)或「X11條款」(X11 License)]

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

要點:商業軟件可以使用,也可以修改MIT協議的代碼,甚至可以出售MIT協議的代碼。


MPL ( Mozilla Public License 1.1 ) 

MPL協議允許免費重發布、免費修改,但要求修改後的代碼版權歸軟件的發起者 。這種授權維護了商業軟件的利益,它要求基於這種軟件的修改無償貢獻版權給該軟件。這樣,圍繞該軟件的所有代碼的版權都集中在發起開發人的手中。但MPL是允許修改,無償使用得。MPL軟件對鏈接沒有要求。

要點:商業軟件可以使用,也可以修改MPL協議的代碼,但修改後的代碼版權歸軟件的發起者。



CDDL (Common Development and Distribution License ) 

CDDL(Common Development and Distribution License,通用開發與銷售許可)開源協議,是MPL(Mozilla Public License)的擴展協議,它允許公共版權使用,無專利費,並提供專利保護,可集成於商業軟件中,允許自行發佈許可。

要點:商業軟件可以使用,也可以修改CDDL協議的代碼。



Common Public License 1.0 (CPL-1.0 )(已廢棄)

CPL是IBM提出的開源協議,主要用於IBM或跟IBM相關的開源軟件/項目中(例如,Eclipse、Open Laszlo等)。

EPL (Eclipse Public License 1.0 ) 

EPL允許Recipients任意使用、複製、分發、傳播、展示、修改以及改後閉源的二次商業發佈。


使用EPL協議,需要遵守以下規則:

1. 當一個Contributors將源碼的整體或部分再次開源發佈的時候,必須繼續遵循EPL開源協議來發布,而不能改用其他協議發佈.除非你得到了原“源碼”Owner 的授權;

2. EPL協議下,你可以將源碼不做任何修改來商業發佈.但如果你要發佈修改後的源碼,或者當你再發布的是Object Code的時候,你必須聲明它的Source Code是可以獲取的,而且要告知獲取方法;

3. 當你需要將EPL下的源碼作爲一部分跟其他私有的源碼混和着成爲一個Project發佈的時候,你可以將整個Project/Product以私人的協議發佈,但要聲明哪一部分代碼是EPL下的,而且聲明那部分代碼繼續遵循EPL;

4. 獨立的模塊(Separate Module),不需要開源。


要點:商業軟件可以使用,也可以修改EPL協議的代碼,但要承擔代碼產生的侵權責任。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章