瞭解開源協議:常用開源協議解析
瞭解開源協議:常用開源協議解析 收藏
開源在今天的軟體業已經很普遍,但開源是否意味著使用者可以對開源後的程式碼為所欲為呢?答案是否定的。開源運動同樣有自己的遊戲規則和道德準則。不遵行這些規則不但損害開源運動的健康發展,也會對違規者造成名譽和市場上的損失,更可能陷入法律糾紛和賠償。
現今存在的開源協議很多,而經過Open Source Initiative組織透過批准的開源協議目前有58種。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。如果要開源自己的程式碼,最好也是選擇這些被批准的開源協議。
這裡我們來看四種最常用的開源協議及它們的適用範圍,供那些準備開源或者使用開源產品的開發人員/廠家參考。
BSD開源協議
BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”為所欲為”,可以自由的使用,修改原始碼,也可以將修改後的程式碼作為開源或者專有軟體再發布。
但”為所欲為”的前提當你釋出使用了BSD協議的程式碼,或則以BSD協議程式碼為基礎做二次開發自己的產品時,需要滿足三個條件:
1. 如果再發布的產品中包含原始碼,則在原始碼中必須帶有原來程式碼中的BSD協議。
2. 如果再發布的只是二進位制類庫/軟體,則需要在類庫/軟體的文件和版權宣告中包含原來程式碼中的BSD協議。
3. 不可以用開原始碼的作者/機構名字和原來產品的名字做市場推廣。
BSD程式碼鼓勵程式碼共享,但需要尊重程式碼作者的著作權。BSD由於允許使用者修改和重新發布程式碼,也允許使用或在BSD程式碼上開發商業軟體釋出和銷售,因此是對商業整合很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的程式碼,在必要的時候可以修改或者二次開發。
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
我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵程式碼重用的許可很不一樣。GPL的出發點是程式碼的開源/免費使用和引用/修改/衍生程式碼的開源/免費使用,但不允許修改後和衍生的程式碼做為閉源的商業軟體釋出和銷售。這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商業軟體公司開發的免費軟體了。
GPL協議的主要內容是隻要在一個軟體中使用(“使用”指類庫引用,修改後的程式碼或者衍生程式碼)GPL協議的產品,則該軟體產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的”傳染性”。GPL協議的產品作為一個單獨的產品使用沒有任何問題,還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開原始碼,商業軟體或者對程式碼有保密要求的部門就不適合整合/採用作為類庫和二次開發的基礎。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開原始碼,商業軟體或者對程式碼有保密要求的部門就不適合整合/採用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
LGPL
LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL允許商業軟體透過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的程式碼。這使得采用LGPL協議的開原始碼可以被商業軟體作為類庫引用併發布和銷售。
但是如果修改LGPL協議的程式碼或者衍生,則所有修改的程式碼,涉及修改部分的額外程式碼和衍生的程式碼都必須採用LGPL協議。因此LGPL協議的開原始碼很適合作為第三方類庫被商業軟體引用,但不適合希望以LGPL協議程式碼為基礎,透過修改和衍生的方式做二次開發的商業軟體採用。
GPL/LGPL都保障原作者的智慧財產權,避免有人利用開原始碼複製並開發類似的產品。
本文來自CSDN部落格,轉載請標明出處:http://blog.csdn.net/beick/archive/2005/04/18/352863.aspx
連結:http://blog.csdn.net/beick/archive/2005/04/18/352863.aspx
連結:http://blog.csdn.net/beick/archive/2005/04/18/352863.aspx
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23650854/viewspace-686801/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 常用開源協議商用限制解讀協議
- 開源協議協議
- 常見開源協議詳解協議
- 大白話開源協議協議
- 看懂開源許可協議協議
- 主流開源協議對比協議
- 開源協議的分類協議
- 開源≠免費 常見開源協議介紹協議
- ASP.NET Core 修改開源協議為MIT,.NET全平臺 MIT協議開源了ASP.NET協議MIT
- Fecbbc多商戶正式開源免費,BSD開源協議協議
- 瞭解HTTP協議HTTP協議
- 開源 | SOFAMesh 的通用協議擴充套件協議套件
- 開源軟體許可協議介紹協議
- 何為開源,聊聊軟體開發中的那些開源協議協議
- 認識流媒體協議,從 RTSP 協議解析開始!協議
- 瞭解HTTP/2協議HTTP協議
- 5W1H聊開源之What——開源協議有哪些?協議
- 螞蟻金服開源的 SOFAMesh 的通用協議擴充套件解析協議套件
- [轉]程式設計師都應該瞭解下版權和開源協議程式設計師協議
- IPIDEA帶你瞭解HTTP協議和SOCKS5協議IdeaHTTP協議
- Elastic開源協議改了,使用者怎麼辦?AST協議
- 相信開源的力量:Nebula Graph 採用 Apache 2.0 作為其開源協議Apache協議
- ARP(地址解析協議)和RARP(逆地址解析協議)協議
- 阿里自研標準化協議庫 XQUIC 正式開源!阿里協議UI
- 【協議】AAA Radius協議的常用報文分析協議
- 引入外部資源協議寫法協議
- 在選擇開源時需要基於自身需求選擇合適的開源協議協議
- 為何《貢獻者許可協議》不利於開源社群?協議
- ARP 地址解析協議協議
- HTTP 協議完全解析HTTP協議
- ios 面向協議程式設計資源iOS協議程式設計
- 帶你瞭解TCP/IP協議族TCP協議
- 瞭解下SOAP HTTP 協議HTTP協議
- 一行命令為專案檔案新增開源協議頭協議
- Modbus常用功能碼協議詳解協議
- Http協議常用知識HTTP協議
- 網路通訊協議-ICMP協議詳解!協議
- 網路通訊協議-TCP協議詳解!協議TCP
- 網路通訊協議-HTTP協議詳解!協議HTTP