一文看懂開源許可證丨開源知識科普

在很多人眼中，「開源」是一個時髦且有情懷的詞彙，始終伴隨有理想主義色彩，因此不少公司開始給自己貼上“開源”標籤。但一個優秀的開源專案遠遠不止是簡單的公開原始碼，而是需要將其當作公司戰略進行貫徹，才能架設起牢不可破的信任橋樑。

PingCAP 從第一行程式碼開源，六年裡積累了一些經驗和教訓，在《開源知識科普》欄目中，我們將與大家分享和交流在開源成長路徑中的思考和感受，以及參與開源專案的正確姿勢。本期話題就從開源的基礎——開源許可證開始，希望對大家瞭解開源、參與開源有一定幫助。

 

近年來，開源正在變得越來越火，我們經常會看到 “某企業宣佈開源”、“某開源大會召開”、“某開源專案獲得融資”。個人開發者與企業比以往任何時候都更願意參與到開源專案的建設和貢獻中，開源在國內 IT 領域獲得了前所未有的熱度，也獲得了產業界和投資圈的廣泛關注。

但總有些人聽到開源一詞時，就會誤以為 “開源軟體是免費的，因此我可以不受限制地隨意使用”。在開源誕生之初，自由軟體是當時的主流提法，回顧開源的發展史，從自由軟體到開源運動實現了非常大的跨越，前者更多的是一種精神的倡導，而後者著眼於軟體的協同開放，因此會有非常嚴謹的開源許可證的規則和限制。開源軟體能走到今天的發展程度，就是因為有了這麼一套遵從開源精神的規則體系，才能夠健康發展。開源精神的載體之一就是開源許可證，今天我們就來扒一扒開源許可證與開源的關係，以及它背後折射出的問題。

什麼是開源許可證？（“Open Source License”）

首先需要明確的是，開源軟體原始碼的著作權既沒有被放棄也沒有過期，其修改和發行等仍然要受到著作權法或者開源軟體許可證的制約。

 

我們接觸到的開源軟體一般都有對應的開源許可證（Open Source License）對軟體的使用、複製、修改和再發布等進行限制。許可證即授權條款，開源許可證就是保證開源軟體這些限制的法律檔案，目的在於規範受著作權保護的軟體的使用或者分發行為。開源許可證是開源軟體生態系統的基礎，可以促進軟體的協同開發。

常見開源許可證

常見的開源許可證主要有 Apache、MIT、BSD、GPL、LGPL、MPL、SSPL 等，可以大致分為兩大類：寬鬆自由軟體許可協議（“Permissive free software licence”）和著佐權許可證（“copyleft license”）。

 

Permissive free software licence 是一種對軟體的使用、修改、傳播等方式採用最低限制的自由軟體許可協議條款型別。這種型別的軟體許可協議將不保證原作品的派生作品會繼續保持與原作品完全相同的相關限制條件，從而為原作品的自由使用、修改和傳播等提供更大的空間。

而 Copyleft License 是在有限空間內的自由使用、修改和傳播，且不得違背原作品的限制條款。如果一款軟體使用 Copyleft 型別許可協議規定軟體不得用於商業目的，且不得閉源，那麼後續的衍生子軟體也必須得遵循該條款。

兩者最大的差別在於：在軟體被修改並再發行時， Copyleft License 仍然強制要求公開原始碼（衍生軟體需要開源），而 Permissive free software licence 不要求公開原始碼（衍生軟體可以變為專有軟體）。

其中，Apache、MIT、BSD 都是寬鬆許可證，GPL 是典型的強著佐權（copyleft ）許可證，LGPL、MPL 是弱著佐權（copyleft ）許可證。SSPL 則是近年來 MongoDB 建立的一個新許可證，存在較大爭議，開放原始碼促進會 OSI 甚至認為 SSPL 就不是開源許可協議。

此外，還有一類是 Creative Commons（CC）知識共享協議。嚴格意義上說該協議並不能說是真正的開源協議，它們大多是被使用於設計類的工程上。CC 協議種類繁多，每一種都授權特定的權利。大多數的比較嚴格的 CC 協議會宣告 “署名權，非商業用途，禁止衍生” 條款，這意味著你可以自由的分享這個作品，但你不能改變它和對其收費，而且必須宣告作品的歸屬。這個許可協議非常的有用，它可以讓你的作品傳播出去，但又可以對作品的使用保留部分或完全的控制。最少限制的 CC 協議型別當屬 “署名” 協議，這意味著只要人們能維護你的名譽，他們對你的作品怎麼使用都行。

來源：http://moqod.com/mobile-web-software-development/

可以看出，不同許可證之間的差異非常大，你可能會困惑，搞得這麼複雜的目的是什麼呢？

這就不得不從開源的歷史講起了。

開源這個詞最初其實是指開源軟體（OSS）。開源軟體是原始碼可以任意獲取的計算機軟體，任何人都能檢視、修改和分發他們認為合適的程式碼。在開源領域中，存在著兩大陣營：FSF（Free Software Foundation，自由軟體基金會) 和 OSI（Open Source Initiative，開放原始碼促進會），他們對開源有著不同的理念。

FSF 是開源泰斗 RMS 創立的重要的開源軟體基金會 (1985/10/04), FSF 創立之初主要是為了籌集資金來建設 GNU 的核心 Hurd 專案及工具鏈，雖然 GNU 專案本身沒有完成，但是該過程中創造出的大量軟體工具，日後成為了 GNU/Linux 的重要組成部分。為了貫徹 RMS 對 “自由” 和 “開源” 的理解，FSF 建立了開源領域的第一個 “copyleft” 屬性的許可證 - GPL (GNU Public License) 。

OSI 由開源界泰斗 Bruce Perens 和 Eric S. Raymond (ESR) 在 1998 年組建，目的是在原教旨主義開源 (最早的開源運動發起和推動者們) 與軟體工業/商業之間激烈矛盾中，尋求更平衡的體系和治理機制。OSI 組織批准過的許可大概有 80 種，包括 Apache License v2、GPL v2、MIT/BSD 等。

FSF 與 OSI 是推廣和維護開源秩序的非盈利組織，維護著 “開源” 的定義以及主要的開源軟體協議遞交、討論與稽核。只要條款被稽核通過是符合開放原始碼定義的，就可以稱之為開放原始碼授權條款，採用開放原始碼條款散佈授權的軟體即是開放原始碼軟體，若一份商業產品中包含有開放原始碼軟體，其包裝上可以標上開放原始碼促進會的證明標章，認識這個標章的消費者就可以知道產品中有使用到開放原始碼軟體，進而因為開放原始碼軟體特有的優點而購買產品。

下面，我們通過一張表來簡單瞭解一下常見開源許可證之間的區別：

來源：http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html

其中，Apache 許可證（Apache License）license 是一個由 Apache 軟體基金會發布的自由軟體許可證，最初為 Apache http 伺服器而撰寫。此許可證最新版本為 “版本 2”，於 2004 年 1 月釋出。Apache 許可證鼓勵程式碼共享和最終原作者的著作權，允許原始碼修改和再發布。但是需要遵循以下條件：

• 需要給程式碼的使用者一份 Apache Licence；

 

• 如果修改了程式碼，需要在被修改的檔案中說明；

 

• 在衍生的程式碼中（修改和有原始碼衍生的程式碼中）需要帶有原來程式碼中的協議，商標，專利宣告和其他原來作者規定需要包含的說明；

 

• 如果再發布的產品中包含一個 Notice 檔案，則在 Notice 檔案中需要帶有 Apache Licence。你可以在 Notice 中增加自己的許可，但是不可以表現為對 Apache Licence 構成更改；

 

• Apache Licence 也是對商業應用友好的許可。使用者也可以在需要的時候修改程式碼來滿足並作為開源或商業產品釋出/銷售。

   

例如，在一個使用 Apache 許可證的開源專案中，其下游 Fork 的企業不僅沒有回饋上游開源專案，反而將衍生的程式碼更改為不受 OSI 認可的 SSPL Licence，另行宣佈成為一個新的開源專案，誤導了很多不明真相的人，以為又湧現出一個新的開源專案。但該行為其實已經對原開源專案的合法權益造成了侵害，也有背開源精神。

作為從第一天就以開源作為發展基礎的開源基礎軟體公司，PingCAP 鮮明地反對一些在開源軟體領域 “違背開源精神，破壞遊戲規則” 的行為。

PingCAP 目前開源的專案包含 TiDB、TiKV 及 Chaos Mesh®，都是基於 Apache 2.0 的協議來開發和運營的，任何個人、公司、雲廠商，只要不違反 Apache 2.0 協議的相關規定，都可以自由地去下載、研讀、改寫、編譯原始碼，甚至可以發行自己的發行版，進行相應的商業活動。

PingCAP 在設計這個公司的時候，就在為開源做持續貢獻的設計作準備，比如在開源治理體系上，我們認為自己就是開源技術體系的一部分，並設有專門的團隊持續運營開源社群。

在開源技術體系中，開源社群是整個新技術創新的上游源頭，也是創新技術的孵化器。開源社群不斷推動各種開源專案，並通過全球協作實現產品的快速迭代。通過這種源頭創新的方式，可以不斷把創新技術通過全球社群協作的方式 “生產” 出來，開源社群實際上已經變成了新技術的創新引擎。

在剛剛釋出的《開源社群成熟度研究報告》 2.0 中，TiDB 社群被作為開源社群運營和治理實踐典範作為研究物件，探索開源社群的健康可持續發展。報告中還首次提出了開源社群成熟度模型與開源社群度量體系，對開源感興趣的同學可以點選原文連結下載。

作為開源生態的一員，我們歡迎任何人蔘與到開源事業中，共同繁榮開源領域，開源今天的局面來之不易，需要所有參與其中的人共同維護，敬畏遊戲規則，遵從開源精神，才能創造開源的美好明天。

附：

常見開源許可證介紹：

• Apache：Apache 許可證（Apache License），是一個由 Apache 軟體基金會發布的自由軟體許可證，最初為 Apache http 伺服器而撰寫。Apache 許可證要求被授權者保留著作權和放棄權利的宣告，但它不是一個反著作權的許可證。此許可證最新版本為 “版本2”，於 2004 年 1 月釋出。Apache 許可證是寬鬆的，因為它不會強制派生和修改作品使用相同的許可證進行釋出。

 

• MIT：MIT 許可證之名源自麻省理工學院（Massachusetts Institute of Technology, MIT），又稱 “ X 條款”（X License）或 “ X11 條款”（X11 License）。MIT 內容與三條款 BSD 許可證（3-clause BSD license）內容頗為近似，但是賦予軟體被授權人更大的權利與更少的限制。有許多團體均採用 MIT 許可證。例如著名的 ssh 連線軟體 PuTTY 與 X Window System (X11) 即為例子。Expat 、Mono 開發平臺庫、Ruby on Rails、 Lua 5.0 onwards 等等也都採用 MIT 授權條款。

 

• BSD：BSD 許可協議（ Berkeley Software Distribution license ）是自由軟體中使用廣泛的許可協議之一。BSD 就是遵照這個許可證來發布，也因此而得名 BSD 許可協議。BSD 包最初所有者是加州大學的董事會，這是由於 BSD 源自加州大學伯克利分校。BSD 開始後，BSD 許可協議得以修正，使得以後許多 BSD 變種，都採用類似風格的條款。跟其他條款相比，從 GNU 通用公共許可證（GPL）到限制重重的著作權（Copyright），BSD 許可證比較寬鬆，甚至跟公有領域（Public Domain）更為接近。事實上，BSD 許可證被認為是 copycenter（中間著作權），介乎標準的 copyright 與 GPL 的 copyleft 之間。"Take it down to the copy center and make as many copies as you want"。可以說，GPL 強迫後續版本必須一樣是自由軟體，BSD 的後續版本可以選擇要繼續是 BSD 或其他自由軟體條款或閉源軟體等等。

 

• GPL：GPL 協議和 BSD、Apache Licence 等鼓勵程式碼重用的許可很不一樣。GPL 的出發點是程式碼的開源/免費使用和引用/修改/衍生程式碼的開源/免費使用，但不允許修改後和衍生的程式碼做為閉源的商業軟體釋出和銷售。由於 GPL 嚴格要求使用了 GPL 類庫的軟體產品必須使用 GPL 協議，對於使用 GPL 協議的開原始碼，商業軟體或者對程式碼有保密要求的部門就不適合整合/採用此作為類庫和二次開發的基礎。

 

• LGPL：LGPL 是 GPL 的一個為主要為類庫使用設計的開源協議。和 GPL 要求任何使用/修改/衍生自 GPL 類庫的的軟體必須採用 GPL 協議不同。LGPL 允許商業軟體通過類庫引用 (link) 方式使用 LGPL  類庫而不需要開源商業軟體的程式碼。這使得采用 LGPL 協議的開原始碼可以被商業軟體作為類庫引用併發布和銷售。但是如果修改 採用 LGPL 協議的程式碼或者對其進行衍生，則所有修改的程式碼，涉及修改部分的額外程式碼和衍生的程式碼都必須採用 LGPL 協議。因此採用 LGPL 協議的開原始碼很適合作為第三方類庫被商業軟體引用，但不適合希望以採用 LGPL 協議的程式碼為基礎，通過修改和衍生的方式做二次開發的商業軟體採用。

 

• SSPL：SSPL 是 MongoDB 建立的一個原始碼可用的許可證，以體現開源的原則，同時提供保護，防止公有云供應商將開源作品作為服務提供而不回饋此開源作品。SSPL 允許自由和不受限制的使用和修改開源作品，但如果你把此開源作品作為服務提供給別人，你也必須在 SSPL 下公開發布任何修改以及管理層的原始碼。開放原始碼促進會 OSI 對 SSPL 頗有微詞，它認為 SSPL 不是開源許可協議，實際上是一個原始碼可用的許可證。

 

• Elastic License：Elastic License 是非商業許可證，核心條款是如果將產品作為 SaaS 使用則需要獲得商業授權。