身為程序員，我們不可避免的要和開源項目打交道，不管是我們自己做了些開源項目，還是使用開源項目，對各種開源協議的了解是必要的。
這篇文章旨在短時間內讓讀者朋友們對常見的開源協議有了了解，在創建自己開源項目時可以靈活選用協議，在使用開源項目時也可以避免踩到開源協議的坑。
基于上述目的，文章篇幅不長，如果感覺不過癮，建議多讀幾遍～

文章概覽

一、OSI(Open Source Initiative)

OSI，開發源代碼組織，是一個旨在推動開源軟件發展的非盈利組織。目前受到 OSI 承認的開源協議一共 83 種，具體協議可以在 OSI 官網 查看。

二、在 Github 上如何添加開源協議

我們在 Github 上創建一個開源項目時，新建一個名為 LICENSE 的文件時，就會彈出選擇開源協議的按鈕，我們點進去就可以看到，Github 默認支持的協議模板。點擊協議會有詳細的介紹。

我們下面就看看這幾種協議的內容，以及在這幾種協議中如何去選擇。協議的具體內容在這里不做解讀，因為實在是篇幅不短，先聊聊其中的重點。

三、Apache 2.0

3.1 關鍵詞

修改代碼需要說明

3.2 關鍵點

需要保留原有作者的聲明

如果修改了代碼，需要進行說明

不承擔責任

可以新增許可，但不能對 Apache 協議造成更改

3.3 商業化

可用于商業

3.4 舉個栗子

小益使用 Apache 協議開源了一個 Android 類庫，只要小張引用類庫時保留了原作者的聲明，并對修改的源碼進行說明，那后續項目開源與否，都是符合協議的。

3.5 使用此協議的開源項目

hadoop，tomcat

四、BSD 2

4.1 關鍵詞

聲明協議

4.2 關鍵點

再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議

如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔那個和版權聲明中包含原來代碼中的BSD協議

4.3 商業化

允許閉源商業軟件的發布和銷售

4.4 使用此協議的開源項目

brew

五、BSD 3

5.1 關鍵詞

聲明協議

5.2 關鍵點

相比 BSD 2.0 新增協議如下： 不可以用開源代碼的“作者/機構的名字”或“原來產品的名字”做市場推廣

5.3 商業化

允許閉源商業軟件的發布和銷售

5.4 舉個栗子

小益使用 BSD 協議開源了一個 Android 類庫，只要小張引用類庫時保留了原作者的聲明，并對修改的源碼進行說明，那后續項目開源與否，都是符合協議的。

5.5 使用此協議的開源項目

flask，redis，numpy

六、MIT

6.1 關鍵詞

許可聲明

6.2 關鍵點

軟件中必須包含許可聲明

6.3 商業化

允許商業化

6.4 舉個栗子

小益使用 MIT 協議開源了一個 Android 類庫，只要小張引用類庫時保留包含了許可聲明，那后續項目開源與否，都是符合協議的。

6.5 使用此協議的開源項目

vue，react，bootstrap，vscode，electron，axios，terminal

七、GPL 2.0

7.1 關鍵詞

感染

7.2 關鍵點

使用 / 修改 / 衍生 GPL 類庫的代碼或軟件，必須也采用 GPL 協議進行開源

項目開源后可以再增加其他開源協議，但是協議必須比 GPL 寬泛

不提供品質擔保，使用采用此協議的軟件產生的任何后果都不會負責

7.3 商業化

可以用于商業，但是必須開放源碼

7.4 舉個栗子

小益使用 GPL 協議開源了一個 Android 類庫，這個時候小張做開發時，本著不重復造輪子的想法，在項目中引用了小益的類庫。項目開發完成以后，小張想把項目上架到 GooglePlay，但是不想開源，這個時候就違反了 GPL 協議。 為了不違反協議，小張索性將項目開源，而在選擇開源協議的時候，小張必須選擇 GPL 協議。

GPL 的本質就是生生不息，不斷衍生。

7.5 使用此協議的的開源項目

Linux，GCC，scapy

八、GPL 3.0

GPL 3.0 相比 2.0 新增了一些條例：

任何向 GPL 項目貢獻的成果將永遠以 GPL 協議發行

GPL 軟件設備的用戶有權更改軟件

使用此協議的的開源項目

GIMP，Bash，YouCompleteMe

九、LGPL

9.1 關鍵詞

引用類庫無需開源

9.2 關鍵點

LGPL 允許商業軟件通過引用(link)的方式使用 LGPL 類庫，而不需要開放源代碼

但是如果修改或衍生 LGPL 協議代碼，則必須采用 LGPL 協議

9.3 商業化

適合商業軟件

9.4 舉個栗子

小益使用 LGPL 協議開源了一個 Android 類庫，小張做開發時引用了此類庫。之后小張將項目上架到 GooglePlay 而不開源，是沒有違反協議的。但是小張引用類庫時，是以源碼的形式引用的，那就必須要將項目開源了。

9.5 使用此協議的的開源項目

alibaba/jvm-sandbox

十、AGPL 3.0

10.1 關鍵詞

網絡交互

10.2 關鍵點

AGPL 在 GPL 的基礎上，增加了一條限制，通過網絡與用戶交互，也需要提供源代碼

10.3 商業化

可以用于商業，但是必須開放源碼

10.4 使用此協議的開源項目

octotree

十一、EPL 2.0

11.1 關鍵詞

修改源碼需要開源

11.2 關鍵點

修改源碼后發布需要開源

軟件貢獻者再次將源碼開源發布時，需要使用 EPL 協議，除非得到作者授權

項目中引用了 EPL 協議的代碼，項目開源時可以使用其他協議，但是引用的那部分代碼仍然需要使用 EPL 協議

11.3 商業化

允許閉源商業軟件的發布和銷售

11.4 使用此協議的開源項目

che

十二、MPL

12.1 關鍵詞

版權集中

12.2 關鍵點

修改后的代碼版權歸軟件的發起者，可以免費使用

12.3 商業化

允許閉源商業軟件的發布和銷售

12.4 舉個栗子

小益使用 MPL 協議開源了一個 Android 類庫，小張對源碼進行修改以后重新發布，修改后的源碼版權也屬于小益。

12.5 使用此協議的開源項目

syncthing，firefox-ios

十三、如何選擇開源協議

如果想省事，不關系別人用自己的代碼去做什么，直接選 MIT 或者 BSD 就好

如果想代碼修改以后做出聲明，選擇 Apache 協議

如果想“繁衍”后代，那么使用 GPL 協議

其實看了上述介紹，了解了各個協議之間的區別，我們基本上也就清楚項目該選哪種協議了。如果還不清楚，可參照此 網站。

總結

參考

zh.wikipedia.org/wiki/GNU通用公…
www.gnu.org/licenses/ol…
jxself.org/translation…
www.cnblogs.com/onlycxue/ar…

后續會不l定期更新五分鐘系列，內容主要集中在一些不太需要深入的技術點，旨在讓讀者朋友們快速了解一些技術概念， 歡迎大家關注下面賬號，獲取最新技術文章：
公眾號：ZYLAB
Github
掘金
知乎

總結

以上是生活随笔為你收集整理的五分钟看懂开源协议的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。