五分鐘看懂開源協議

【這是 ZY 第 12 篇原創技術文章】

身爲程序員，咱們不可避免的要和開源項目打交道，不論是咱們本身作了些開源項目，仍是使用開源項目，對各類開源協議的瞭解是必要的。
這篇文章旨在短期內讓讀者朋友們對常見的開源協議有了瞭解，在建立本身開源項目時能夠靈活選用協議，在使用開源項目時也能夠避免踩到開源協議的坑。
基於上述目的，文章篇幅不長，若是感受不過癮，建議多讀幾遍～

文章概覽

1、OSI(Open Source Initiative)

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

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

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

咱們下面就看看這幾種協議的內容，以及在這幾種協議中如何去選擇。協議的具體內容在這裏不作解讀，由於實在是篇幅不短，先聊聊其中的重點。

3、Apache 2.0

3.1 關鍵詞

修改代碼須要說明

3.2 關鍵點

1. 須要保留原有做者的聲明
2. 若是修改了代碼，須要進行說明
3. 不承擔責任
4. 能夠新增許可，但不能對 Apache 協議形成更改

3.3 商業化

可用於商業

3.4 舉個栗子

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

3.5 使用此協議的開源項目

hadoop，tomcat

4、BSD 2

4.1 關鍵詞

聲明協議

4.2 關鍵點

1. 再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議
2. 若是再發布的只是二進制類庫/軟件，則須要在類庫/軟件的文檔那個和版權聲明中包含原來代碼中的BSD協議

4.3 商業化

容許閉源商業軟件的發佈和銷售

4.4 使用此協議的開源項目

brew

5、BSD 3

5.1 關鍵詞

聲明協議

5.2 關鍵點

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

5.3 商業化

容許閉源商業軟件的發佈和銷售

5.4 舉個栗子

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

5.5 使用此協議的開源項目

flask，redis，numpy

6、MIT

6.1 關鍵詞

許可聲明

6.2 關鍵點

1. 軟件中必須包含許可聲明

6.3 商業化

容許商業化

6.4 舉個栗子

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

6.5 使用此協議的開源項目

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

7、GPL 2.0

7.1 關鍵詞

感染

7.2 關鍵點

1. 使用 / 修改 / 衍生 GPL 類庫的代碼或軟件，必須也採用 GPL 協議進行開源
2. 項目開源後能夠再增長其餘開源協議，可是協議必須比 GPL 寬泛
3. 不提供品質擔保，使用採用此協議的軟件產生的任何後果都不會負責

7.3 商業化

能夠用於商業，可是必須開放源碼

7.4 舉個栗子

小益使用 GPL 協議開源了一個 Android 類庫，這個時候小張作開發時，本着不重複造輪子的想法，在項目中引用了小益的類庫。項目開發完成之後，小張想把項目上架到 GooglePlay，可是不想開源，這個時候就違反了 GPL 協議。 爲了避免違反協議，小張索性將項目開源，而在選擇開源協議的時候，小張必須選擇 GPL 協議。

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

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

Linux，GCC，scapy

8、GPL 3.0

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

1. 任何向 GPL 項目貢獻的成果將永遠以 GPL 協議發行
2. GPL 軟件設備的用戶有權更改軟件

使用此協議的的開源項目

GIMP，Bash，YouCompleteMe

9、LGPL

9.1 關鍵詞

引用類庫無需開源

9.2 關鍵點

1. LGPL 容許商業軟件經過引用(link)的方式使用 LGPL 類庫，而不須要開放源代碼
2. 可是若是修改或衍生 LGPL 協議代碼，則必須採用 LGPL 協議

9.3 商業化

適合商業軟件

9.4 舉個栗子

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

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

alibaba/jvm-sandbox

10、AGPL 3.0

10.1 關鍵詞

網絡交互

10.2 關鍵點

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

10.3 商業化

能夠用於商業，可是必須開放源碼

10.4 使用此協議的開源項目

octotree

11、EPL 2.0

11.1 關鍵詞

修改源碼須要開源

11.2 關鍵點

1. 修改源碼後發佈須要開源
2. 軟件貢獻者再次將源碼開源發佈時，須要使用 EPL 協議，除非獲得做者受權
3. 項目中引用了 EPL 協議的代碼，項目開源時可使用其餘協議，可是引用的那部分代碼仍然須要使用 EPL 協議

11.3 商業化

容許閉源商業軟件的發佈和銷售

11.4 使用此協議的開源項目

che

12、MPL

12.1 關鍵詞

版權集中

12.2 關鍵點

1. 修改後的代碼版權歸軟件的發起者，能夠無償使用

12.3 商業化

容許閉源商業軟件的發佈和銷售

12.4 舉個栗子

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

12.5 使用此協議的開源項目

syncthing，firefox-ios

十3、如何選擇開源協議

1. 若是想省事，不關係別人用本身的代碼去作什麼，直接選 MIT 或者 BSD 就好
2. 若是想代碼修改之後作出聲明，選擇 Apache 協議
3. 若是想「繁衍」後代，那麼使用 GPL 協議

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

總結

參考

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

後續會不按期更新五分鐘系列，內容主要集中在一些不太須要深刻的技術點，旨在讓讀者朋友們快速瞭解一些技術概念，

關於我