現今存在的開源協議很多，而經過Open Source Initiative組織通過批准的開源協議目前有58種（http://www.opensource.org/licenses /alphabetical）。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批准的協議。如果要開源自己的程式碼，最好也是選擇這些被批准的開源協議。

這裡我們來看四種最常用的開源協議及它們的適用範圍，供那些準備開源或者使用開源產品的開發人員/廠家參考。

BSD開源協議（original BSD license、FreeBSD license、Original BSD license）

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”為所欲為”,可以自由的使用，修改原始碼，也可以將修改後的程式碼作為開源或者專有軟體再發布。

但”為所欲為”的前提當你釋出使用了BSD協議的程式碼，或則以BSD協議程式碼為基礎做二次開發自己的產品時，需要滿足三個條件：

   1. 如果再發布的產品中包含原始碼，則在原始碼中必須帶有原來程式碼中的BSD協議。
   2. 如果再發布的只是二進位制類庫/軟體，則需要在類庫/軟體的文件和版權宣告中包含原來程式碼中的BSD協議。
   3. 不可以用開原始碼的作者/機構名字和原來產品的名字做市場推廣。

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等類似。

關於開源協議GPL　V2和V3

單從開源行業的GPL協議上來看，似乎開源linux產品上的一切是可以無條件的開放和共享的，但是從實際的操作來看，在GPL相對的許可授權之下，又有其相對封閉的一面，就這次的GPL v2到GPL v3的修訂改版來說，正是GPL協議“封閉”一面的具體體現。

根據GPL v2的相關規定：只要這種修改文字在整體上或者其某個部分來源於遵循GPL的程式，該修改文字的整體就必須按照GPL流通，不僅該修改文字的原始碼必須向社 會公開，而且對於這種修改文字的流通不准許附加修改者自己作出的限制。而在GPL v3的修訂草案中，不僅要求使用者公佈修改的原始碼，還要求公佈相關硬體，恰恰是這一條，由於觸及和其他相關數字版權管理(DRM)及其產品的關係，並且也 由於有和開源精神相違的地方，所以備受爭議，甚至因此也遭到了有著“LINUX之父”之稱的託瓦爾茲的反對。

從表面上看，GPL v2到GPL v3的升級之困只不過是對協議修訂過程中某一條款的分歧，而更為嚴重的是在兩種協議都合法存在的前提下，具體的開源軟體或者開源產品的所有者有權選擇是遵 循GPL v2協議還是恪守GPL v3協議，因此衝突也就來了，這種衝突正如中科紅旗的CTO鄭忠源描述的那樣：“世界有如此多軟體都在GPL v2的約束之下，而自由軟體是集合全世界程式設計師勞動，即使是貢獻一行程式碼，如果該程式設計師只同意這一程式碼只遵循GPL v2之下，就不能隨便去修改協議。如果計劃將軟體轉移到GPL v3之下，理論上講，必須徵得所有程式碼人的同意。但是目前還很難確定有多少開發人員願意轉移到新版本之下，如果有的人願意轉，有的人不願意轉，這其中就有 很多的麻煩；而如果多數人都不願意改變，那這一事情也許就無聲無息……”

通過業內人士的精闢描述，相信大家一定對開源行業和開源軟體產品有了一個全新的認識吧，就那熟悉的LINUX系統來說，雖然表面上看起來大家有權按 照自己的需要和目的進行任意的改寫重組，但是在諸多的獨立程式面前，別人是隻能共享使用，而無權修改的，當然獲得授權就另當別論了。而就GPL v2到GPL v3的協議升級來說，這種協議的選擇上的分歧實際上也是開源行業裡一種觀念認知上的相左，到底誰的選擇是正確的？絕對不是一兩句話能說得清的，尤其是在各 種利益交織之下。

情勢之下，開源社群的GPL v2與GPL v3選擇之困很現實的會在相當一段時間內給這個行業及其產品造成“相容問題”，說白了就是兩種協議以及兩種協議之下的矛盾，不管是人的還是產品的都將會持 續下去，而這種僵持對整個開源行業來說未必是一件好事，最起碼從“精神”方面來說這個行業已經在開始分道揚鑣。

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一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的宣告,無論你是以二進位制釋出的還是以原始碼釋出的. 開源協議 出處：http://www.cnblogs.com/Wayou/p/how_to_choose_a_license.html

相信很多剛踏入軟體這個行業的小夥伴一如當初的我，對開源軟體的各種協議不甚瞭解被搞昏了頭腦。畢竟對於一個新生程式設計師來說，如何寫好程式碼才是亟待解決的問題，無暇瞭解這些。隨著你專案做得多了程式碼寫得多了，你會發現編碼過程中會不時用到其他人的成果，一個專案下來多少會引入一些優秀的庫，別人放在公網上開源的DLL，以及一些演算法等等。細心的你會注意到即使只是一小段程式碼，優秀的作者都在最開始會簡單地附上一段關於許可的宣告，或者說是協議比如"Licensed under the MIT license"，並且一些部落格也會標明"此文章發表在CC協議下"。而如果我們Copy了別人的程式碼或者文字同時沒注意這些的話，在國外法律意識特別強的環境下，我們的作品會因觸犯別人的權益而違法。因為好多開源協議最低要求是使用者需要保留原作者對程式碼的宣告，不聲不響地就拿來用了必然導致惡果。

所以開源不等於免費，開源也不等於沒有約束。

何為License

License是軟體的授權許可，裡面詳盡表述了你獲得程式碼後擁有的權利，可以對別人的作品進行何種操作，何種操作又是被禁止的。軟體協議可分為開源和商業。當然本文要討論的當然是開源協議。

對於商業協議，或者叫法律宣告、許可協議，每個軟體會有自己的一套行文，由軟體作者或專門律師撰寫。這是什麼驚為天人的東西嘛還得請專門的律師。因為涉及到以後侵權打官司這種事情，這種商業條款的行文是非常嚴謹而講究的，記得以前看到句調侃的話：'如果法律檔案不寫得那麼生澀難懂，律師們就沒飯吃了'，就是說任何文字一旦上升到法律的層次，不要說你接受完了九年義務教育，就是考了個專八也會覺得英語白學了，直接的法律協議什麼的那不是給常人看的。而至於法律條款緣何會晦澀難懂，這個偏題有點偏遠了，可以檢視這裡瞭解。看累了？下面是歡樂時刻，奉上一個協議相關的Joke（笑崩！蘋果iOS7升級協議條款中員工神吐槽）。

你丫知道麼？這已經是46頁，肯定沒人讀的。我敢打賭大概只有5個人點了"條款和協議"，所以我們想扯點啥就扯點啥吧。 Apple總部5樓的那個tony總是渾身一股沙丁魚味 有人給我們寄點啥2b向的郵件，我們都得很文藝的用"i笑了"的方式回覆。這是我們的工作規定 還記得當年關於Apple Studio的版權合法性爭議麼？想知道我們怎麼擺平的？我們把披頭士樂隊買下來了。他們中活著的現在沒事來給我們唱兩曲解解悶，死了的，我們想辦法像Miku的3D投影那樣，設法在二次元給他們來個復活 我們餐廳永遠只賣蘋果東西：蘋果，蘋果汁，蘋果煎餅，蘋果棒糖。。。不想丟工作的話我們只能吃這些，而哥恰好對蘋果過敏，哥現在正處於餓的神志不清亂敲鍵盤的節奏。 我們偽造了登月真相。其實美國人登月是2008年的事情，我們向你們洗腦它發生在1969，我們絕對有這種洗腦的本事。如果有人發現我知道的太多了，我就會被查水錶，但是沒關係，沒人會看這頁。

所以對於大多數人來說，不用自己花大把時間去寫許可協議，選擇一分廣為流傳的開源協議是個不錯的選擇，如果你的作品是開源的話，這樣省時又省心。

選擇一分協議的好處

你的作品如果不是定性為全商業性質，可以考慮選擇一分流行度比較高的開源協議。具體來說的話，你肯定希望作品能夠被多數人分享查閱吧，不但提高自己業界的知名度，同時也方便了需要的人為開源做出了貢獻。換句話說，你不分享出來的話你的作品的意義何在呢（當然，自己搗騰的私人東西還是自己保留吧）？可是一旦你把你的程式碼貼出來，這就表示任何人都可以看到並獲取，之後發生的事情你無法控制，有的人或許稍微修改一下放進自己的程式碼中，有的把你的軟體改個名字拿去販賣，有的甚至會拿去把作者名字改為自己然後拿去找工作什麼的，而不會有人知道這個作品的原作者，背後辛勤付出了的人。所以為了公開分享你的程式碼，同時又讓你對程式碼保留一定權利，在作品中宣告一個許可協議是非常有必要的，這是很多新人所忽略的問題，同時很多人在使用別人的勞動成果時也會忽視協議的存在，這樣不好。所以你會看到我的部落格裡面時不時會給出連線指向來源頁面，同時文末也會列出所有參考過的文章。我相信我做到了這點，別人在轉載我的文章的時候，也可以做到這點，這樣營造出來的氛圍一定會非常和諧，互相尊重/Show Respect。

多說一句，一個事實讓你瞭解國外開發者在尊重他人勞動成果方面做得是如何的到位，如果A的作品是因為B的作品的啟發而來，A甚至都沒有使用B任何一句程式碼，但A會在他的作品裡面指明是受到了B的啟發"Inspired by XXX link :http://www.blah.com"。

當然有人會覺得，有了一分協議宣告在那裡，我就需要鳥你麼，我拿來用了把作者名字去掉同時還要加上我的名字，你咬我？！這是後話，只是在利益很小的情況下，或者作者不知情的情況下，作者不會追究什麼責任，但如果你的產品做成功了，那就不一定了。另外就是，有協議和沒宣告協議的裸程式碼是有非常重要區別的，一般作品當中沒宣告協議的預設為Copy right的，也就是版權保留。此種情況表明他人沒有任何授權，不得複製分發修改使用等等，但一如上面所討論的，這樣的話還何來開源，何來分享呢。有了協議的宣告，在未來你的維權上面會方便很多，讓你的作品在分享的同時保留了自身的一些權利。

快速選擇

目前流行的開源協議有很多，並且同一款協議有很多變種，比如你或許看到過' CC Attribution-NoDerivs',' CC Attribution-NonCommercial'同屬CC協議（後面會有介紹）。如此紛繁的協議該如何選擇？協議太寬鬆會導致作者喪失對作品的很多權利，太嚴格又不便於使用者使用及作品的傳播。所以除了協議多之外，你還要考慮你對作品想保留哪些權利，放開哪些限制。

如果你不想了解太多，只是想要一個簡直直接的答案，下面給出的建議或許適合你。下方關於協議的選擇及表格來自GitHub choosealicence專案。

簡單寬鬆的協議

如果你只想要一個簡單點的協議不想太麻煩的話。

MIT協議相對寬鬆但還是抓住了要點的。此協議允許別人以任何方式使用你的程式碼同時署名原作者，但原作者不承擔程式碼使用後的風險，當然也沒有技術支援的義務。jQuery和Rails就是MIT協議。

考慮有專利的情況

如果你的作品中涉及到專利相關。

Apache協議也是個相對寬鬆與MIT類似的協議，但它簡單指明瞭作品歸屬者對使用者專利上的一些授權（我的理解是軟體作品中含有專利，但它授權你可以免費使用）。Apache伺服器，SVN還有NuGet等是使用的Apache協議。

程式碼分享與促進

如果你在乎作品的傳播和別人的修改，希望別人也以相同的協議分享出來。

GPL（V2或V3）是一種版本自由的協議（可以參照copy right來理解，後者是版本保留，那copyleft便是版權自由，或者無版權，但無版權不代表你可以不遵守軟體中宣告的協議）。此協議要求程式碼分發者或者以此程式碼為基礎開發出來的衍生作品需要以同樣的協議來發布。此協議的版本3與版本2相近，只是多3中加了條對於不支援修改後程式碼執行的硬體的限制（沒太明白此句話的內涵）。

各協議授權詳情

下面是更多開源協議的一個表格任君選擇，總有一款是你的菜。

不過先來了解一些下方表格中出現的用詞的解釋：

• 協議和版權資訊(License and copyright notice)：在程式碼中保留作者提供的協議和版權資訊
• 宣告變更(State Changes)：在程式碼中宣告對原來程式碼的重大修改及變更
• 公開原始碼(Disclose Source)：程式碼必需公開。如果是基於LGPL協議 下，則只需使用的開原始碼公開，不必將整個軟體原始碼公開
• 庫引用(Library usage)：該庫可以用於商業軟體中
• 責任承擔(Hold Liable)：程式碼的作者承擔程式碼使用後的風險及產生的後果
• 商標使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商標
• 附加協議(Sublicensing)：允許在軟體分發傳播過程中附加上原來沒有的協議條款等

協議	描述	要求	允許	禁止
一個較寬鬆且簡明地指出了專利授權的協議。	協議和版權資訊 宣告變更	商用 分發 修改 專利授權 私用 附加協議	責任承擔（禁止讓作者承擔責任，可以理解為免責） 商標使用
GPL	此協議是應用最為廣泛的開源協議，擁有較強的版權自由( copyleft )要求。衍生程式碼的分發需開源並且也要遵守此協議。此協議有許多變種，不同變種的要求略有不同。	公開原始碼 協議和版權資訊 宣告變更	商用 分發 修改 專利授權 私用	責任承擔 附加協議
MIT	寬鬆簡單且精要的一個協議。在適當標明來源及免責的情況下，它允許你對程式碼進行任何形式的使用。	協議和版權資訊	商用 分發 修改 私用 附加協議	責任承擔
Perl社群尤為鍾愛此協議。要求更改後的軟體不能影響原軟體的使用。	協議和版權資訊 宣告變更	商用 分發 修改 私用 附加協議	責任承擔 商標使用
BSD	較為寬鬆的協議，包含兩個變種BSD 2-Clause 和BSD 3-Clause，兩者都與MIT協議只存在細微差異。	協議和版權資訊	商用 分發 修改 私用 附加協議	責任承擔
對商用非常友好的一種協議，可以用於軟體的商業授權。包含對專利的優雅授權，並且也可以對相關程式碼應用商業協議。	公開原始碼 協議和版權資訊	商用 分發 修改 專利授權 私用 附加協議	責任承擔
LGPL	主要用於一些程式碼庫。衍生程式碼可以以此協議釋出（言下之意你可以用其他協議），但與此協議相關的程式碼必需遵循此協議。	公開原始碼 庫引用 協議和版權資訊	商用 分發 修改 專利授權 私用 附加協議	責任承擔
Mozilla Public License(MPL 2.0)是由Mozilla基金建立維護的。此協議旨在較為寬鬆的BSD協議和更加互惠的GPL協議中尋找一個折衷點。	公開原始碼 協議和版權資訊	商用 分發 修改 專利授權 私用 附加協議	責任承擔 商標使用
你保留所有權利，不允許他人分發，複製或者創造衍生物。當你將程式碼發表在一些網站上時需要遵守該網站的協議，此協議可能包含了一些對你勞動成果的授權許可。比如你將程式碼釋出到GitHub，那麼你就必需同意別人可以檢視和Fork你的程式碼。	協議和版權資訊	商用 私用	分發 修改 附加協議
在許多國家，預設版權歸作者自動擁有，所以Unlicense協議提供了一種通用的模板，此協議表明你放棄版權，將勞動成果無私貢獻出來。你將喪失對作品的全部權利，包括在MIT/X11中定義的無擔保權利。	N/A	商用 分發 修改 私用	責任承擔

非程式碼類作品的協議

上面各協議只是針對軟體或程式碼作品，如果你的作品不是程式碼，比如視訊，音樂，圖片，文章等，共享於公眾之前，也最好宣告一下協議以保證自己的權益不被侵犯。針對非程式碼的數字作品的協議，最通用的莫過於Creative Commons(也是你經常在別人部落格下面可以看到的CC協議)協議。所以現在你見到部落格園別人文章下面的簽名就不會感到陌生了。

無協議

你沒有義務也沒人非要你必需在自己的程式碼作品裡面加上一個開源協議。但一如上文所討論過的優點，如果你想把程式碼分享出來，最好還是選擇一個適合的開源協議，這樣別人用著放心。

出處：http://baike.baidu.com/link?url=31W-VzhlcYrTqmSdnO_69Ep9F0mPBVxPJMgLEvoxW65nYMiBbzOeAbFerhbEU7riqJlKdo7f07VbUrVUexcryK

開源協議

 編輯

本詞條缺少名片圖，補充相關內容使詞條更完整，還能快速升級，趕緊來編輯吧！ LGPL許可證是LESSER GENERAL PUBLIC LICENSE的簡寫，也叫LIBRARY GENERAL PUBLIC LICENSE，中文譯為“較寬鬆公共許可證”或者“函式庫公共許可證”。該許可證適用於一些由自由軟體基金會與其它決定使用此許可證的軟體作者所特殊設計的軟體軟體包─比如函式庫（即Library）。

中文名

開源協議

外文名

LESSER GENERAL PUBLIC LICENSE的

別    名

LGPL許可證

例    如

函式庫

目錄

1. 1 簡介
2. 2 MPL
3. 3 BSD
4. 4 QPL
5. 5 QNCL

1. 6 Jab
2. 7 Com
3. 8 IBM
4. 9 協議比較
5. ▪ BSD

1. ▪ AL2.0
2. ▪ GPL
3. ▪ LGPL
4. ▪ MIT

簡介

編輯 除了大家比較熟悉的GPL協議之外，開源界還有很多許可證，如LGPL許可證、BSD許可證等，下面就來一一介紹。 LGPL許可證，也是自由軟體聯盟GNU開源軟體許可證的一種，大部分的 GNU軟體，包括一些函式庫，是受到原來的 GPL許可證保護的。而LGPL許可證，適用於特殊設計的函式庫，且與原來的通用公共許可證有很大的不同，給予了被許可人較為寬鬆的權利，所以叫“較寬鬆公共許可證”。在特定的函式庫中使用它，以准許非自由的程式可以與這些函式庫連結。 當一個程式與一個函式庫連結，不論是靜態連結或使用共享函式庫，二者的結合可以合理地說是結合的作品，一個原來的函式庫的衍生品。因此，原來的通用公共許可證只有在整個結合品滿足其自由的標準時，才允許連結。較寬鬆通用公共許可則以更寬鬆的標準允許其它程式程式碼與本函式庫連結。例如，在少數情況下，可能會有特殊的需要而鼓勵大家儘可能廣泛地使用特定的函式庫，因而使它成為實際上的標準。為了達到此目標，必須允許非自由的程式使用此函式庫。一個較常發生的情況是，一個自由的函式庫與一個被廣泛使用的非自由函式庫做相同的工作，在此情況下，限制只有自由軟體可以使用此自由函式庫不會有多少好處，故我們使用了LGPL許可證。 在其他情況下，允許非自由程式使用特定的函式庫，可以讓更多的人們使用自由軟體的大部分。例如，允許非自由程式使用GNU C函式庫，可以讓更多的人們使用整個GNU作業系統，以及它的變形，GNU/Linux作業系統。 儘管LGPL許可證對使用者的自由保護是較少的，但它卻能確保與此函式庫連結的程式的使用者擁有自由，而且具有使用修改過的函式庫版本來執行該程式的必要方法。

MPL

編輯