9個主流的開源許可協議[整理]

關於開源許可

現今存在的開源協議不少，而通過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協議，須要遵照如下規則：

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

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

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

四、開發或維護遵循 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協議的代碼，但要承擔代碼產生的侵權責任。

----------------------------------------------------------------------

參考資料：

經常使用開源協議詳細解析  - cnBeta

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

經常使用開源協議簡要介紹