技術分享 | 如何為你的代碼選擇一個合適的開源協議？

近期公司全面擁抱開源，在選擇開源協議方面遇到了一些問題，查閱了很多資料，特此總結~~

前言

對於很多剛踏入開源軟件這個行業的小伙伴來說，在編碼過程中難免會用到其他人的成果，如果你足夠細心，很容易注意到即使是一小段代碼，優秀的作者都在文件開頭附上一段關於版權的聲明，比如 Licensed under the MIT license。同時，一些博客也會標明”此文章采用 CC BY 4.0 CN 協議“。

如果我們拷貝了別人的代碼或文章卻沒注意版權問題，在國外法律意識特別強的環境下（國內版權意識也在逐步加強），那么我們的作品會因觸犯別人的權益而違法。即使是最開放的開源協議，最低要求也是保留原作者對代碼的聲明，所以開源不等於免費，也不等於沒有約束。

何為 LICENCE？

LICENCE 是軟件的授權許可，詳細說明了獲得代碼后擁有的權利，哪些操作是允許的，哪些操作是禁止的。軟件的版權許可證可有很多方式，本文僅限於討論開源軟件協議 Open Source License。

對於大多數人來說，沒必要花大把時間去寫許可協議，選擇一種比較流行的開源協議就足夠了，省時省力，更便於自己作品的傳播，於人於己都有利。

PS：

說句題外話，很多國外開發者在尊重他人勞動成果方面做得很好，如果A的作品是因為B的作品的啟發而來，A甚至都沒有使用B任何一句代碼，但A會在他的作品里面指明是受到了B的啟發：Inspired by XXX link: http://www.xxxx.com。

快速選擇開源協議

如果你不想了解太多，只是想要一個簡直直接的答案，下面給出的建議或許適合你。本小節關於協議地址來自於 GitHub choosealicence 。

簡單寬松的協議：

如果你只想要一個簡單點的協議不想太麻煩的話。

MIT協議相對寬松，此協議允許別人以任何方式使用你的代碼同時署名原作者，但原作者不承擔代碼使用后的風險，當然也沒有技術支持的義務。

考慮有專利的情況：

如果你的作品中涉及到專利相關。

Apache協議也是個相對寬松的協議，與MIT類似，但它指明了作者對用戶專利上的一些授權（我的理解是軟件作品中含有專利，但它授權你可以免費使用）。

促進代碼分享：

如果你在乎作品的傳播和別人的修改，希望別人也以相同的協議分享出來。

GPL（V2或V3）協議要求代碼分發者或者以此代碼為基礎開發出來的衍生作品需要以同樣的協議來發布，也必須開源，因此，該協議具有”傳染性“。

烏克蘭程序員 Paul Bagwell 畫了一張分析圖，說明應該怎么選擇。只用兩分鍾，你就能搞清楚這六種開源協議之間的最大區別。

國內大神阮一峰的漢化版本：

主流開源許可協議（Open Source License）

世界上的開源許可協議（Open Source License）大概有上百種，常用的開源軟件協議大致有：

• GPL
• LGPL
• BSD
• MIT
• Mozilla
• Apache

由寬松到嚴緊排序，常用的開源協議有：

1. MIT
2. BSD
3. Apache
4. LGPL
5. GPL

主要區別：

• MIT、BSD 開源協議都源自大學，體現了簡單、開放和包容的特點。
• MIT、BSD、Apache 三者都支持閉源的后續開發。
• GPL、LGPL 傳染性開源，編譯的代碼里用了這里的代碼，都必須開源。

MIT

來源於大學，MIT 開源協議是史上最為簡潔、慷慨的開源協議之一。作者只想保留版權，而無任何其他了限制。也就是說，你必須在你的發行版里包含原許可協議的聲明，無論你是以二進制發布的還是以源代碼發布的。

特點：

• 用戶可以拿你的代碼做任何想做的事情。
• 用戶在項目副本中要包含版權聲明和許可聲明。
• 你無需承擔任何責任。

代表作品：

• jQuery
• Rails 等。

BSD

• BSD-2-Clause
• BSD-3-Clause

BSD可證也來源於大學，與MIT差不多，也非常簡單、慷慨。

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以”為所欲為”,可以自由的使用、修改源代碼，也可以將修改后的代碼作為開源或者專有軟件再發布。前提是當你發布使用了BSD協議的代碼，或者以BSD協議代碼為基礎開發自己的產品時，需要滿足三個條件：

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

BSD 開源協議鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD 開源協議允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟件發布、銷售，是對商業集成很友好的協議。因此，很多公司在選用開源產品的時候都首選BSD協議。

Apache Licence

• Apache License, Version 2.0
• Apache License, Version 1.1
• Apache License, Version 1.0

來自 Apache，類似 MIT 開源協議，但它重視專利權。

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

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

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

代表作品：

• echarts
• superset
• dubbo
• spark

LGPL

LGPL（GNU LESSER GENERAL PUBLIC LICENSE）來自於自由軟件聯盟GNU，可以翻譯為更寬松的GPL協議，也屬於傳染性開源協議。

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

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

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

GPL

GPL（GNU GENERAL PUBLIC LICENSE）來源於自由軟件聯盟GNU，GPL/LGPL側重於代碼及衍生代碼的開源與免費使用。

GPL協議的主要內容是只要在一個軟件中使用（”使用”指類庫引用，修改后的代碼或者衍生代碼）GPL 協議的產品，則該軟件產品必須也采用GPL協議，既必須也是開源和免費。這就是所謂的”傳染性”。

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

我們很熟悉的Linux就是采用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用/引用/修改和衍生代碼的開源/免費使用，但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。

其它細節和BSD/Apache等協議類似。

代表作品：

• Linux

更多開源協議對比

下方表格中出現的用詞的解釋：

• 協議和版權信息(License and copyright notice)：在代碼中保留作者提供的協議和版權信息。
• 聲明變更(State Changes)：在代碼中聲明對原來代碼的重大修改及變更。
• 公開源碼(Disclose Source)：代碼必需公開。
• 庫引用(Library usage)：該庫可以用於商業軟件中。
• 責任承擔(Hold Liable)：代碼的作者承擔代碼使用后的風險及產生的后果。如果禁止，那么作者將不會承擔責任，可以理解為免責條款。
• 商標使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商標。
• 附加協議(Sublicensing)：允許在軟件分發傳播過程中附加上原來沒有的協議條款等。

協議	描述	要求	允許	禁止
Apache	一個比較寬松且簡明地指出了專利授權的協議。	1. \(\color{#0000FF}{協議和版權信息}\) 2. \(\color{#0000FF}{聲明變更}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\)（作者免責） 2. \(\color{#FF3030}{商標使用}\)
GPL	應用最廣泛的開源協議，擁有較強的版權自由（copyleft）要求。 衍生代碼的分發需開源並且也要遵守此協議。 此協議有許多變種，不同變種的要求略有不同。	1. \(\color{#0000FF}{公開源碼}\) 2. \(\color{#0000FF}{協議和版權信息}\) 3. \(\color{#0000FF}{聲明變更}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\)	1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{附加協議}\)
MIT	此協議寬松簡單。在適當標明來源及免責的情況下，它允許你對代碼進行任何形式的使用。	1. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\)
Artistic	Perl社區最鍾愛此協議。要求更改后的軟件不能影響原軟件的使用。	1. \(\color{#0000FF}{協議和版權信息}\) 2. \(\color{#0000FF}{聲明變更}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{商標使用}\)
BSD	較為寬松的協議，有兩個變種BSD 2-Clause 和BSD 3-Clause，兩者都與MIT協議只存在細微差異。	1. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\) 5. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\)
Eclipse	對商用非常友好的協議，可以用於軟件的商業授權。包含對專利的優雅授權，也可以對相關代碼應用商業協議。	1. \(\color{#0000FF}{公開源碼}\) 2. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\)
LGPL	主要用於一些代碼庫。衍生代碼可以以此協議發布（也可以用其他協議），但與此協議相關的代碼必需遵循此協議。	1. \(\color{#0000FF}{公開源碼}\) 2. \(\color{#0000FF}{庫引用}\) 3. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\)
Mozilla	Mozilla Public License(MPL 2.0)是由Mozilla基金創建維護的，旨在較為寬松的BSD協議和更加互惠的GPL協議中找一個折衷點。	1. \(\color{#0000FF}{公開源碼}\) 2. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{專利授權}\) 5. \(\color{#00EE00}{私用}\) 6. \(\color{#00EE00}{附加協議}\)	1. \(\color{#FF3030}{責任承擔}\) 2. \(\color{#FF3030}{商標使用}\)
No license	作者保留所有權利，不允許他人分發，復制或者創造衍生物。 當你將代碼發表在一些網站上時需要遵守該網站的協議，此協議可能包含了一些對你勞動成果的授權許可。比如將代碼發布到GitHub，那么就必須同意別人查看和fork。	1. \(\color{#0000FF}{協議和版權信息}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{私用}\)	1. \(\color{#FF3030}{分發}\) 2. \(\color{#FF3030}{修改}\) 3. \(\color{#FF3030}{附加協議}\)
Public domain dedication	在許多國家，默認版權歸作者自動擁有，所以Unlicense協議提供了一種通用的模板。 此協議表明作者放棄版權，將勞動成果無私貢獻出來，會喪失作品全部權利，包括在MIT/X11中定義的無擔保權利。	1. \(\color{#0000FF}{N/A}\)	1. \(\color{#00EE00}{商用}\) 2. \(\color{#00EE00}{分發}\) 3. \(\color{#00EE00}{修改}\) 4. \(\color{#00EE00}{私用}\)	1. \(\color{#FF3030}{責任承擔}\)

參考鏈接

• https://github.com/github/choosealicense.com
• https://opensource.org/licenses
• https://www.cnblogs.com/Wayou/p/how_to_choose_a_license.html
• https://zhuanlan.zhihu.com/p/87855729

---

歡迎關注我的微信公眾號【數據庫內核】：分享主流開源數據庫和存儲引擎相關技術。

標題	網址
GitHub	https://dbkernel.github.io
知乎	https://www.zhihu.com/people/dbkernel/posts
思否（SegmentFault）	https://segmentfault.com/u/dbkernel
掘金	https://juejin.im/user/5e9d3ed251882538083fed1f/posts
開源中國（oschina）	https://my.oschina.net/dbkernel
博客園（cnblogs）	https://www.cnblogs.com/dbkernel