01 開源license，是啥?
場景：壯壯是一個程式設計師，他最近開發了一個小功能，並且將代碼放到了github上。過了一段時間，壯壯發現，好多人引用他的代碼，但沒有聲稱他的著作權，壯壯覺得很氣憤，且不理解：為什麼大家這麼不尊重我的勞動成果呢?所以他就問他的好朋友小源同學，小源同學了解情況後，告訴他：是因為你沒有採用符合你需求的license啊!
license，中文譯為「許可證」。在開源世界裡，license是具有法律效力的，通過選擇相應的license，版權擁有者可以聲稱自己相應的權利，包括其他人使用、修改、引用、共享等一系列涉及版權的操作。
實際上，目前國際上公認的開源許可證有80餘種，如果對開源了解不多的人，確實會覺得僅許可證一項就很複雜，但在實際使用許可證時，我們可以將使用場景歸納一下，並且將一些常用的許可證種類列舉並解釋，就極大的方便開發者選用合適的許可證了。下面一道就梳理一下那些常用的許可證~
02 開源license，咋用?
故事：Stallman是自由軟體之父，他在上世紀八十年代開發GNU系統時，創造了Copyleft一詞，用以區分商業公司copyright。實際上，在上世紀七、八十年代，就已經有相當一部分開源許可證被發布出來，供開源軟體選擇使用。
如上圖所示：Copyright是目前商業公司採用的版權保護辦法，旨在杜絕用戶之間通過複製、分發等形式，共享產品，造成商業利益的損失;
Public domain則屬於另一極端，即在未聲明任何license的情況下，著作者與著作物不存在任何關聯。
我們所講的開源license，則集中在Copyleft和Permissive兩類情況中，具化來講，可以理解為：
Copyleft：衍生代碼必須開源，且採用相同的開源license;
Permissive：衍生代碼不必開源，可採用不同的開源license;
所以，作為代碼的生產者，無論是個人抑或是公司，可以確立自身在面對開源時的原則，進而能夠確定自身所選定的license類型。
03 開源license，有哪些?
如前文所述，國際公認的開源license，有多達80餘種，理解起來殊無必要。只要掌握常用的幾類，在需要的時候，採用相應的license，即可解決許可證相關問題。
至於更多的時間精力，不如留給繼續coding或者撩妹~
1GPL
全稱為General Public License，是Stallman老爺子在鼓搗GNU時所採用的開源協議。GPL最特殊的一點在於：只要一個軟體使用了GPL協議的產品，則該軟體也必須採用GPL協議，即衍生或修改後的代碼，不可用於閉源的商業軟體銷售和發布。
這種特性，使得GPL具有病毒的特性——傳染性。但GPL的傳染是為了所有相關代碼能夠開放，使更多人受益。
2BSD
全稱為Berkeley Software Distribution，是一個較為寬鬆的開源協議，唯一關注的是保護代碼作者的著作權要受到尊重，這給予使用者很大的自由度。在滿足二次發布時需要聲明原來代碼的BSD協議及不將原作者/產品用作市場推廣時，，使用者可以自由的使用、修改源碼，甚至在源碼基礎上二次開發後進行商用發布和銷售。
3MIT
全稱為Massachusetts Institution of Technology，又名「X條款」，MIT與BSD較為類似，差異較小。僅提供版權保護和聲明，即在二次開發後的發行版中，需要包含原許可證聲明。
4MPL
全稱為Mozilla Public License，是網景公司的Mozilla小組於1998年設計的軟體許可證。該許可證介於GPL和BSD之間，是為了更好的平衡「開發者對源碼的需求和他們利用原始碼獲得的收益」。比如MPL協議下，可以通過折中辦法，隱藏具有商業訴求的原始碼，為商用場景提供了許可。MPL協議規定較為詳細，感興趣的讀者可以自行搜索該協議，作進一步的研究。
5Apache License 2.0
沒錯，該許可協議就是來自於大名鼎鼎的Apache Software Foundation，總體來說，該許可協議與BSD/MIT協議類似，屬於比較寬鬆、商業友好的開源協議。只需要使用者在使用了該協議下的原始碼後， 再發布後，依然帶有對原始碼的協議、商標、及其他作者規定的說明，即可。
6LGPL
全稱為Lesser General Public License，亦稱GPL V2，雖然它與GPL同出一處，但他具有不同性：LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。但如果是修改LGPL的代碼或者衍生的代碼，則所有修改或衍生的代碼，均需要遵循LGPL協議。
04 開源license，用哪個?
開源license，並沒有嚴格地講孰優孰劣，只有在根據實際的使用場景，才能明確開源license的最佳選擇。
「道理我都懂，可還是過不好這一生」，那麼不妨，我們從兩個小故事中窺探開源license的真假浮沉吧~~
故事一
2016年5月，Facebook開源了自身的前端軟體React，引來業界震動。
7月，Facebook在React開源許可協議中的附加專利條款開始引發爭議。
11月，Facebook官方澄清附加專利條款，但並未獲得認同，業界仍然憂心忡忡。
2017年7月，Apache基金會禁止使用遵循BSD+附加專利條款的jar包。
同時，中國網際網路的一批企業開始意識到問題嚴重性，並且積極抵制該協議，並且尋求新的前端技術以替代React。
10月，Facebook迫於壓力，宣布將react及其他一系列採用BSD+專利許可協議的軟體改用MIT許可協議。
點評：BSD+專利許可協議的精髓是「如果你覺得Facebook侵犯了你的智慧財產權，你不能起訴Facebook;如果Facebook起訴你，那麼你不能反訴，否則你就立即停止使用React」。
瞧瞧!小扎很精明嘛!
可惜!群眾也不傻呀!
故事二
2009年，甲骨文宣布收購SUN公司。本來是一件正常的商業行為，但卻有一個人堅決反對，他就是Michael Widenius——MySQL的創始人。可他為什麼反對呢?
因為MySQL是SUN公司所有，一旦被收購，就將屬於Oracle公司。而眾所周知，Oracle和MySQL那可是死敵啊!MySQL的未來境遇，可想而知。於是Michael Widenius甚至發起了萬人籤名，提交請願書，要求歐盟委員會否決這項交易。
當然，歷史的進程已經表明：SUN還是被Oracle收購了;MySQL並沒有因此而死掉;這又是為什麼呢?
因為MySQL採用的是GPL協議，按照該協議：任何源碼的衍生產品，如果對外發布，都必須採用相同的許可協議。即我們前邊提到的「傳染性」。也就是說，在MySQL已經被廣泛採用的情況下，使用的GPL協議，反而成為了他最好的保護傘，因為即使Oracle公司廢棄MySQL，其他企業或個人依然可以發布MySQL的最新版本和特性;從另外一個角度講，Oracle公司捨不得MySQL的規模和技術，如果在此基礎上進行修改，則二次發布的產品因為GPL協議的傳染性，也不得不採用該協議，依然使得MySQL或者重生。
但如果MySQL一開始使用的是MIT/BSD等協議，那麼Oracle很容易將MySQL併入自己的商業產品中，並且通過一系列新的特性和功能，使得開源版本被邊緣化。
回過頭看，開源協議之威力，竟至於斯!
05 寫在最後：簡單粗暴的選擇你的開源協議
烏克蘭程式設計師Paul Bagwell畫了一張分析圖，介紹了最為流行的幾種開源license的實際使用情況。國內技術牛人漢化過來，貼在此處，供大家參考。