現今存在的開源協議很多，而經過
open source initiative
組織通過批准的開源協議目前有58種（我們在常見的開源協議如bsd, gpl, lgpl,mit等都是osi批准的協議。如果要開源自己的**，最好也是選擇這些被批准的開源協議。
這裡我們來看四種最常用的開源協議及它們的適用範圍，供那些準備開源或者使用開源產品的開發人員/廠家參考。
bsd開源協議（original bsd license、freebsd license、original bsd license）
bsd開源協議是乙個給於使用者很大自由的協議。基本上使用者可以」為所欲為」,可以自由的使用，修改源**，也可以將修改後的**作為開源或者專有軟體再發布。
但」為所欲為」的前提當你發布使用了bsd協議的**，或則以bsd協議**為基礎做二次開發自己的產品時，需要滿足三個條件：
1. 如果再發布的產品中包含源**，則在源**中必須帶有
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類似：
1. 需要給**的使用者乙份apache licence
2. 如果你修改了**，需要再被修改的檔案中說明。
3. 在延伸的**中（修改和有源**衍生的**中）需要帶有原來**中的協議，商標，專利宣告和其他原來作者規定需要包含的說明。
4. 如果再發布的產品中包含乙個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一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的宣告,無論你是以二進位制發布的還是以源**發布的.
gnu lgpl
gnu 還有另外一種協議，叫做 lgpl （lesser general public licence），它對產品所保留的權利比 gpl 少，總的來說，lgpl 適合那些用於非 gpl 或非開源產品的開源類庫或框架。因為 gpl 要求，使用了 gpl **的產品必須也使用 gpl 協議，開發者不允許將 gpl **用於商業產品。lgpl 繞過了這一限制。
bsdbsd 在軟體分發方面的限制比別的開源協議（如 gnu gpl）要少。該協議有多種版本，最主要的版本有兩個，新 bsd 協議與簡單 bsd 協議，這兩種協議經過修正，都和 gpl 相容，並為開源組織所認可。
mitmit 協議可能是幾大開源協議中最寬鬆的乙個，核心條款是：
該軟體及其相關文件對所有人免費，可以任意處置，包括使用，複製，修改，合併，發表，分發，再授權，或者銷售。唯一的限制是，軟體中必須包含上述版權和許可提示。
這意味著：
* 你可以自由使用，複製，修改，可以用於自己的專案。
* 可以免費分發或用來盈利。
* 唯一的限制是必須包含許可宣告。
mit 協議是所有開源許可中最寬鬆的乙個，除了必須包含許可宣告外，再無任何限制。
apache
apache 協議 2.0 和別的開源協議相比，除了為使用者提供版權許可之外，還有專利許可，對於那些涉及專利內容的開發者而言，該協議最適合（這裡有一篇文章闡述這個問題）。
apache 協議還有以下需要說明的地方:
* 永久權利
一旦被授權，永久擁有。
* 全球範圍的權利
在乙個國家獲得授權，適用於所有國家。假如你在美國，許可是從印度授權的，也沒有問題。
* 授權免費，且無版稅
前期，後期均無任何費用。
* 授權無排他性
任何人都可以獲得授權
* 授權不可撤消
一旦獲得授權，沒有任何人可以取消。比如，你基於該產品**開發了衍生產品，你不用擔心會在某一天被禁止使用該**。
分發**方面包含一些要求，主要是，要在宣告中對參與開發的人給予認可幷包含乙份許可協議原文。
creative commons
creative commons (cc) 並非嚴格意義上的開源許可，它主要用於設計。creative commons 有多種協議，每種都提供了相應授權模式，cc 協議主要包含 4 種基本形式：
* 署名權
必須為原始作者署名，然後才可以修改，分發，複製。
* 保持一致
作品同樣可以在 cc 協議基礎上修改，分發，複製。
* 非商業
作品可以被修改，分發，複製，但不能用於商業用途。但商業的定義有些模糊，比如，有的人認為非商業用途指的是不能銷售，有的認為是甚至不能放在有廣告的**，也有人認為非商業的意思是非盈利。
* 不能衍生新作品
你可以複製，分發，但不能修改，也不能以此為基礎創作自己的作品。
這些許可形式可以結合起來用，其中最嚴厲的組合是「署名，非商用，不能衍生新作品」，意味著，你可以分享作品，但不能改動或以此盈利，而且必須
延伸資源
* creative commons licenses
creative common 許可的官方條款與解釋
* open source initiative
包含各種開源協議資源
* open source licenses comparison
對主流開源協議的對比
* understanding open-source licensing
開源協議詳解
* how to: pick an open source license
如何選擇不同的開源協議
為原作者署名。在這種許可模式下，原始作者對作品還擁有完全的控制權，而最寬鬆的組合是「署名」，意味著，只要為原始作者署名了，就可以自由處置。
開源界的5大開源許可協議
越來越多的開發者與設計者希望將自己的產品開源，以便其他人可以在他們的 基礎上做更多事，開源社群也因此充滿生機。在我們所能想到的應用領域，都有開源軟體存在 象 wordpress，drupal 這些開源cms 然而很多人對開源許可並不了解，本文介紹開源領域常用的幾種許可協議以及它們之間的區別。不管產品...
開源界的 5 大開源許可協議
開源界的 5 大開源許可協議 越來越多的開發者與設計者希望將自己的產品開源，以便其他人可以在他們的 基礎上做更多事，開源社群也因此充滿生機。在我們所能想到的應用領域，都有開源軟體存在 象 wordpress，drupal 這些開源cms 然而很多人對開源許可並不了解，本文介紹開源領域常用的幾種許可協...
五大開源許可協議簡介與區別概述
越來越多的開發者與設計者希望將自己的產品開源，以便其他人可以在他們的 基礎上做更多事，開源社群也因此充滿生機。在我們所能想到的應用領域，都有開 源軟體存在 象 wordpress，drupal 這些開源cms 然而很多人對開源許可並不了解，本文介紹開源領域常用的幾種許可協議以及它們之間的區別。什麼是...