扒一扒开源世界有哪些licenses？
摘要：license，中文譯為“許可證”。在開源世界里，license是具有法律效力的，通過選擇相應的license，版權擁有者可以聲稱自己相應的權利，包括其他人使用、修改、引用、共享等一系列涉及版權的操作。
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的實際使用情況。國內技術牛人漢化過來，貼在此處，供大家參考。
總結
以上是生活随笔為你收集整理的扒一扒开源世界有哪些licenses？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： SAP 电商云 Spartacus Ma
- 下一篇： 什么是 SAP Spartacus 里的