1. 程式人生 > >扒一扒開源世界有哪些licenses?

扒一扒開源世界有哪些licenses?

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的實際使用情況。國內技術牛人漢化過來,貼在此處,供大家參考。

原文:https://www.csdn.net/article/a/2018-04-12/15945401