爲何要使用「開源協議」--開源軟件誕生3

選擇開源協議--第3篇

用日誌記錄「開源軟件」的誕生

進入連接，點亮星標，感謝支持

加微信與開發者交流（請註明赤龍ERP） kzca2000

碼雲：https://gitee.com/redragon/redragon-erp

GitHub：https://github.com/redragon1985/redragon-erp

爲何要使用開源協議

爲何要用開源協議呢？這就不得不說說我本人的經歷了。當我想把本身研發的開源軟件發佈之時，我忽然有一個擔憂，就是版權如何保護？雖然這是一款開源免費的軟件，但怎麼能證實和保護本身的著做權呢，怎麼能讓這款軟件遠離利益的趨勢，一直開源下去呢？

固然從法律的角度我首先想到了軟著，即計算機軟件著做權。這是受國家法律保護的一個軟件版權的證實。我還經過多種方式瞭解了它的申請流程及法律效力。但在過程當中忽然發現一個致命的問題。就是關於軟件的版本。從原則上來說，軟著不支持大版本的更新迭代，即若是出現新的軟件版本更新，要想受到法律保護，必須從新註冊新的軟著證書。這對於一款開源並不斷迭代的系統來講是絕對不適用的。

那怎麼辦呢，天然想到了開源協議。雖然開源協議，從國內法律角度來說，沒法從根本上保護軟件的版權，可是能夠做爲證實版權的有力依據。並且國外不少國家都廣泛支持開源協議的合法版權保護地位。因此做爲一款開源軟件開源協議必不可少了！

怎麼選擇開源協議

 

先來看下這張圖，這是一個網上很常見的說明開源協議區別的表格。下面用我本身的話簡單總結一下。

• Apache

（1）Apache基金會下有不少知名的開源項目，這些開源項目都遵循Apache的開源協議。因此熟悉度高，背書好

（2）代碼可修改，但要加入代碼說明。並保留原做者的協議和說明。

（3）在與Apache原協議不衝突的狀況下，能夠加入本身的許可協議。

（4）可商用

• BSD

（1）使用者自由的修改

（2）使用者自由的商業使用

• GLP

（1）Linux採用的協議

（2）不容許閉源的商業發佈

（3）不容許修改成其餘協議

• MIT

（1）限制最少最自由的協議

（2）需保留原做者的協議信息

（3）可商用

• EPL

（1）容許閉源的商業發佈

（2）不容許修改成其餘協議

（3）獨立模塊可不開源

如何爲本身的項目加入協議

好了，若是咱們已經選擇了一個合適的開源協議，那如何給本身的項目加入它，並讓使用者知曉呢？很簡單，完成以下步驟便可：

• 在根目錄增長許可協議，即LICENSE，協議內容去官方搜索

• 給每一個文件頭部增長協議及版權說明（最好包括JAVA、HTML、JS、XML等全部文件）