從GitHub上看開源許可證多舛的命運

要是沒有一個適當的開源許可，那么那樣的開源就不能稱之為開源。除非你已經明確地告訴別人他們可以修改和重用你的工作，因為你只給別人看了你的代碼，還沒有把它共享出去。

在 GitHub 上，我們都是開源的忠實粉絲，所以我們需要更好的去更好地了解我們的用戶是如何根據查看公共的、non-forked 存儲庫方面的許可證來選擇適合他們的開源代碼許可證的，所以，做這個調查的目的就是希望鼓勵更多的用戶與他人分享他們的工作。

如果你經常關注這個注冊存儲庫圖表的話，你就會發現注冊存儲庫的比例正在下降，徘徊在 GitHub 20% 的歷史記錄上（加上已 forked 的大約是 30%）。2013 年中期的注冊數量飆升代表我們第一次在 GitHub 上簡化開源許可證的選擇流程獲得了一定程度的成功。更大程度上鼓勵用戶選用合適的開源許可證來開放他們的項目。

實際上，開源許可證的使用情況并不像我們想象的那么樂觀，一起來看看 choosealicense.com 網站之前做的調查：比較一下相對流行的開源許可的利用現狀。下面根據項目許可證在 GitHub.com 上的比例可以看到他們的受歡迎程度：

1.  MIT                     44.69%  
2.  Other                  15.68%  
3.  GPLv2                12.96%  
4.  Apache               11.19%  
5.  GPLv3                 8.88%  
6.  BSD 3-clause      4.53%  
7.  Unlicense            1.87%  
8.  BSD 2-clause      1.70%  
9.  LGPLv3               1.30%  
10.  AGPLv3               1.05% 

不出所料，MIT、Apache 和 GPL 是明顯的領跑者，其中就有 15% 的注冊項目選擇了標準的或者是不標準的開源許可證，而這些許可證根本不在 choosealicense.com 的名單上。

最后，我們應該來研究一下許可證使用情況發生改變的原因。這三個極具特色的許可證（MIT、Apache、GPL）在 2013 年中期開始不斷上揚，其增長的數量是過去六年的總和。開發人員使用 GitHub 是因為他們想與世界分享他們的代碼。數據表明，當我們覺得某一工具使用起來較之前容易得多的時候，那就說明百分之百是開發者做了改進。更多的時候當面對選 擇時，他們還是會選擇開源許可證的，而且非常自由地執行著。

---

說到開源協議，很多人是不怎么清楚，如今的開源協議達到 60 多種，其中主流的包括以下這些。

1. BSD

BSD 開源協議是一個給于使用者很大自由的協議。基本上使用者可以”為所欲為”，可以自由的使用，修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發布。

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

• 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的 BSD 協議。
• 如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的 BSD 協議。
• 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD 由于允許使用者修改和重新發布代碼，也允許使用或在 BSD 代碼上開發商業軟件發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選 BSD 協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。包括蘋果的 MAC OS，Webkit 瀏覽器內核在內的軟件都使用了 BSD 協議。

2. Apache License, Version 2.0

Apache Licence 是著名的非盈利開源組織 Apache 采用的協議。該協議和 BSD 類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟件）。需要滿足的條件也和 BSD 類似：

• 需要給代碼的用戶一份 Apache Licence。
• 如果你修改了代碼，需要在被修改的文件中說明。
• 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
• 如果再發布的產品中包含一個 Notice 文件，則在 Notice 文件中需要帶有 Apache Licence。你可以在 Notice 中增加自己的許可，但不可以表現為對 Apache Licence 構成更改。

Apache Licence 也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售。Apache 旗下的軟件包括 Apache Web 服務器、Hadoop、Open Office 等軟件都是采用的 Apache License。

3. GNU General Public License (GPL)

我們很熟悉的 Linux 就是采用了 GPL。GPL 協議和 BSD， Apache Licence 等鼓勵代碼重用的許可很不一樣。GPL 的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。這也就是為什么我們 能用免費的各種 Linux，包括商業公司的 Linux 和 Linux 上各種各樣的由個人，組織，以及商業軟件公司開發的免費軟件了。

GPL 協議的主要內容是只要在一個軟件中使用（”使用”指類庫引用，修改后的代碼或者衍生代碼）GPL 協議的產品，則該軟件產品必須也采用 GPL 協議，既必須也是開源和免費。這就是所謂的”傳染性”。GPL 協議的產品作為一個單獨的產品使用沒有任何問題， 還可以享受免費的優勢。

由于 GPL 嚴格要求使用了 GPL 類庫的軟件產品必須使用 GPL 協議，對于使用 GPL 協議的開源代碼，商業軟件或者對代碼有保密要求的部門就不適合集成/采用作為類庫和二次開發的基礎。

其它細節如再發布的時候需要伴隨 GPL 協議等和 BSD/Apache 等類似。這也是小米涉嫌違反的一項開源協議。GPL 是最嚴格和最徹底的開源協議。使用該協議最重要的代表就是 Linux 操作系統了，當然也包括一眾跑在 Linux 上的軟件，像著名的圖像處理軟件 GIMP 等也采用了 GPL 協議。

4. GNU Library or “Lesser” General Public License (LGPL)

LGPL 是 GPL 的一個為主要為類庫使用設計的開源協議。和 GPL 要求任何使用/修改/衍生之 GPL 類庫的的軟件必須采用 GPL 協議不同。LGPL 允許商業軟件通過類庫引用（link）方式使用 LGPL 類庫而不需要開源商業軟件的代碼。這使得采用 LGPL 協議的開源代碼可以被商業軟件作為類庫引用并發布和銷售。

但是如果修改 LGPL 協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須采用 LGPL 協議。因此 LGPL 協議的開源代碼很適合作為第三方類庫被商業軟件引用，但不適合希望以 LGPL 協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟件采用。

GPL/LGPL 都保障原作者的知識產權，避免有人利用開源代碼復制并開發類似的產品。

LGPL 出現是因為 GPL 實在太嚴格了，有點類似開源的原教旨主義，這也導致該協議對商業用戶并不友好。而沒有商業化的軟件其發展前景也大多不好，所以 LGPL 就應運而生。

5. Mozilla Public License

MPL 是 The Mozilla Public License 的簡寫，是 1998 年初 Netscape 的 Mozilla 小組為其開源軟件項目設計的軟件許可證。MPL 許可證出現的最重要原因就是，Netscape 公司認為 GPL 許可證沒有很好地平衡開發者對源代碼的需求和他們利用源代碼獲得的利益。同著名的 GPL 許可證和 BSD 許可證相比，MPL 在許多權利與義務的約定方面與它們相同（因為都是符合 OSIA 認定的開源軟件許可證）。但是，相比而言 MPL 還有以下幾個顯著的不同之處：

MPL 雖然要求對于經 MPL 許可證發布的源代碼的修改也要以 MPL 許可證的方式再許可出來，以保證其他人可以在 MPL 的條款下共享源代碼。但是，在 MPL 許可證中對“發布”的定義是“以源代碼方式發布的文件”，這就意味著 MPL 允許一個企業在自己已有的源代碼庫上加一個接口，除了接口程序的源代碼以 MPL 許可證的形式對外許可外，源代碼庫中的源代碼就可以不用 MPL 許可證的方式強制對外許可。這些，就為借鑒別人的源代碼用做自己商業軟件開發的行為留了一個豁口。

MPL 許可證第三條第 7 款中允許被許可人將經過 MPL 許可證獲得的源代碼同自己其他類型的代碼混合得到自己的軟件程序。

對軟件專利的態度，MPL 許可證不像 GPL 許可證那樣明確表示反對軟件專利，但是卻明確要求源代碼的提供者不能提供已經受專利保護的源代碼（除非他本人是專利權人，并書面向公眾免費許可這些源代 碼），也不能在將這些源代碼以開放源代碼許可證形式許可后再去申請與這些源代碼有關的專利。

使用 MPL 協議的軟件主要包括 Mozilla 基金會下面的l瀏覽器 Firefox、FTP 工具 Firezilla、郵件處理軟件 Thunderbird、大名鼎鼎的 BUG 管理系統 Buglzilla 等。

6. MIT license (MIT)

MIT 是和 BSD 一樣寬范的許可協議，作者只想保留版權，而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。

7. EPL (Eclipse Public License 1.0)

使用 EPL 協議，需要遵守以下規則：

• 當一個 Contributors 將源碼的整體或部分再次開源發布的時候，必須繼續遵循 EPL 開源協議來發布，而不能改用其他協議發布。除非你得到了原“源碼”Owner 的授權；
• EPL 協議下，你可以將源碼不做任何修改來商業發布。但如果你要發布修改后的源碼，或者當你再發布的是 Object Code 的時候，你必須聲明它的 Source Code 是可以獲取的，而且要告知獲取方法；
• 當你需要將 EPL 下的源碼作為一部分跟其他私有的源碼混和著成為一個 Project 發布的時候，你可以將整個 Project/Product 以私人的協議發布，但要聲明哪一部分代碼是 EPL 下的，而且聲明那部分代碼繼續遵循 EPL；
• 獨立的模塊（Separate Module），不需要開源。

EPL 允許 Recipients 任意使用、復制、分發、傳播、展示、修改以及改后閉源的二次商業發布。商業軟件可以使用，也可以修改 EPL 協議的代碼，但要承擔代碼產生的侵權責任。

開源軟件現在已經成為整個互聯網的基礎。包括 Linux 操作系統、主流 Web 服務器、常用的瀏覽器引擎、網絡傳輸加密、大數據挖掘等都離不開開源。而開源運動可以持續下去的保證就是這些開源協議。雖然這些協議看上去只是一紙文書， 并沒有太多強制力。但正是這些看上去很奇怪的協議促進了整個軟件行業的發展，使得很多開源軟件成為最重的軟件，而開源也成為最重要的一種開發方式。