1. 程式人生 > >9個主流的開源許可協議

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(獨立模組) ——指的是,參考或藉助“原始碼”開發出來的獨立的,不包含、不依賴於原“原始碼模組”的功能模組。

*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的出發點是程式碼的開源/免費使用和引用/修改/衍生程式碼的開源/免費使用,但不允許修改後和衍生的程式碼做為閉源的商業軟體釋出和銷售。

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協議的程式碼。

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

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

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

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

MIT是和BSD一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的宣告,無論你是以二進位制釋出的還是以原始碼釋出的。

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

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

  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允許Recipients任意使用、複製、分發、傳播、展示、修改以及改後閉源的二次商業釋出。

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

1. 當一個Contributors將原始碼的整體或部分再次開源釋出的時候,必須繼續遵循EPL開源協議來發布,而不能改用其他協議釋出.除非你得到了原“原始碼”Owner 的授權; 2. EPL協議下,你可以將原始碼不做任何修改來商業釋出.但如果你要釋出修改後的原始碼,或者當你再發布的是Object Code的時候,你必須宣告它的Source Code是可以獲取的,而且要告知獲取方法; 3. 當你需要將EPL下的原始碼作為一部分跟其他私有的原始碼混和著成為一個Project釋出的時候,你可以將整個Project/Product以私人的協議釋出,但要宣告哪一部分程式碼是EPL下的,而且宣告那部分程式碼繼續遵循EPL; 4. 獨立的模組(Separate Module),不需要開源。

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