[轉]9個主流的開源許可協議[整理]
阿新 • • 發佈:2018-07-30
額外 .html 源文件 pro 好的 Owner 產品發布 貢獻 article 關於開源許可
現今存在的開源協議很多,而經過Open Source Initiative 組織通過批準的開源協議目前有60多種(http://www.opensource.org/licenses/alphabetical )。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批準的協議。
——指的是開源軟件或項目的使用者。
顯然,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協議的代碼,但要承擔代碼產生的侵權責任。 ---------------------------------------------------------------------- 參考資料: 常用開源協議詳細解析 - cnBeta 五種開源協議的比較(BSD,Apache,GPL,LGPL,MIT) – 整理 常用開源協議簡要介紹 原文鏈接:http://univasity.iteye.com/blog/1292658
基本概念
1.Contributors 和 Recipients Contributors(貢獻者) ——指的是對某個開源軟件或項目提供了代碼(包括最初的或者修改過)的人或實體(退隊、公司、組織等)。 按照貢獻的先後可分為"創始人"(an initial Contributor)和"參與者"(subsequent Contributors)。 Recipients(獲取者)*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 )
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) – 整理 常用開源協議簡要介紹 原文鏈接:http://univasity.iteye.com/blog/1292658
[轉]9個主流的開源許可協議[整理]