軟體是一種著作，天然是擁有版權的。很多人會認為放在
Github
上的就是開源軟體，既然放了源代碼，我就可以随便使用了。其實版權法規定著作是禁止共享的，也就是說沒有許可證的軟體等于保留版權。雖然源代碼公開了，但并不表明你可以随便使用，一用就會侵犯版權。如果軟體侵犯版權，必須明确授予使用者開源許可證。
另外，有一些沒有道德的公司會大量使用開源的産品，進行組合封裝修改後當做自己的勞動創造。這些拿來黨屬于破壞遊戲規則的一群人，這些人也應該讓他們受到應有的懲罰，例如：
GPL
協定就是防止這種情況發生的。
- 軟體著作權的明确，作者（版權方）的權益明确，保護知識成果
- 友善使用者使用，使用者獲得明确的授權（是否可以進行使用、拷貝、修改和再釋出）
- 開源≠免費，免費≠免責， no license≠授權，授權≠收費
版權是知識産權的一種，和著作權是同一個概念，可以自動取得，也可以登記取得，是作者對自己的著作享有的法定權利。著作權是公民、法人依法享有的一種民事權利，屬于無形财産權。享有著作權的作者可以決定是否對他的作品進行著作權意義上的使用和處理，在我國，隻要發表就會受到保護。
開源許可證的種類
我們可以把版權分為四大種。
-
Copyright
-
Copyleft
-
Permissive
-
Create Commons
實際上，一般隻會把
Copyleft
和
Permissive
叫做開源，其中
Permissive
限制比較寬松。而
Copyleft
要求不得用于商業目的且不得閉源，并且後續衍生子軟體必須遵守條款。其實這種協定就是為了弘揚開源精神，不希望某些公司壟斷和強占開發成果。
copyright就是俗稱的版權，也叫著作權。
版權又稱著作權，用來表述創作者因其文學和藝術作品而享有的權利。版權的取得有兩種方式：自動取得和登記取得。在中國，按照著作權法規定，作品完成就自動有版權（百度百科）
在版權的基礎上，作者還可以制定授權協定（license），按照自己的心意進一步界定使用者的權利。
也就是說，作者的具體權利 = 當地法律規定的版權(copyright) + 自己在作品中添加的授權協定(license)。
權利 = 版權(copyright) + 授權協定(license)
比如，商業化的授權協定（license）可能會傾向于強調，使用者的哪些行為是侵權行為，進而保護自己的商業利益。而基于開源思想的授權協定則會強調使用者的權力。
Permissive
寬松自由許可
BSD
(二條版)、
BSD
(三條版)、
MIT
、
Apache2
| | | | |
|---|---|---|---|---|
| 允許修改後閉源 | ✅ | ✅ | ✅ | ✅ |
| 不保證代碼品質 | ✅ | ✅ | ✅ | ✅ |
| 必須披露原始作者 | ✅ | ✅ | ✅ | ✅ |
| 不得使用原始作者名字為軟體推廣 | ✅ | |||
| 分發時必須保留原始許可聲明 | ✅ | |||
| 修改過必須向使用者聲明修改 | ✅ | |||
| 未修改必須保持許可證不變 | ✅ |
Copyleft
有限空間内的自由
GPL
、
Affero GPL (AGPL)
、
LGPL
、
Mozilla（MPL）
| | | | |
|---|---|---|---|---|
| 分發二進制格式，必須提供源碼 | ✅ | ✅ | ✅ | ✅ |
| 修改後，必須與修改前保持許可一緻 | ✅ | ✅ | ✅ | ✅ |
| 不得在原始許可以外附加限制 | ✅ | ✅ | ✅ | ✅ |
| 如果項目包含GPL許可代碼， 整個項目必須開源 | ✅ | |||
| 雲服務用到的代碼， 雲服務代碼必須開源 | ✅ | |||
| 如果項目屬于動态連結庫使用許可證庫 項目不用開源 | ✅ | |||
| 許可證代碼在單獨檔案中 新增其他檔案可以不開源 | ✅ |
前端項目的開源協定
目前前端項目普遍會選擇
MIT
協定。
-
Vue
-
React
-
Element
-
Ant Design
MIT 協定是一種最簡單的開源協定，隻需要保留最基本的版權許可。這個時候就會有人問，為什麼
React
同樣是MIT協定，但是聽說百度要求内部全面停止使用
React
呢？這是因為
React
曾經在開源協定外還增加了附加的條款。
大概意思就是，當發生下列情況時，
Facebook
有權益吊銷你的
React
使用權：
- 與
Facebook
- 同任何一個和
Facebook
- 同任何與 React 有關的組織發生利益沖突。
也就是說，使用 React 的項目，如果和
Facebook
有利益沖突都可能被吊銷React的使用權。這個對于大廠來講肯定不太行，後來這件事不斷發酵，開源社群在更多的
Facebook
開源項目中發現了類似的規定，開發者普遍認為這種許可證模式正在毒害社群。 不過
Facebook
最後還是意識到了這個問題，修改了開源協定。
開源許可證的權力術語
不同的“開源許可證”有不同的授權次元，或者加以限制，又或者要求有條件的使用。
| 名稱 | 中文 | 備注 |
|---|---|---|
| Commercial use | 商業應用 | 指是否可将開源用于商業目的 |
| Distribution | 釋出發行 | 指是否允許釋出發行依賴于此開源的項目 |
| Modification | 修改 | 指是否允許在開源項目上做修改 |
| Patent use | 申請專利 | 指是否允許用于專利申請 |
| Private use | 個人使用 | 指是否允許個人學習，修改和使用 |
| License and copyright notice | 注明協定和版權 | 指是否要求注明協定以及版權說明 |
| State changes | 注明變更 | 指對于開源代碼的修改是否要明确說明 |
| Liability | 義務 | 指開源軟體是否承擔使用其後帶來的義務 |
| Trademark use | 商标使用 | 指開源軟體是否可用在商标或在商标中暗示使用 |
| Warranty | 報修維護 | 指開源軟體是否提供後期維護 |
| Same License | 同協定下 | 指基于開源二次開發的産品若釋出，是否要基于相同或相近的協定之下 |
| Disclose source | 公開源碼 | 指基于開源開發的代碼是否也需要開源 |
如何選擇開源協定？
可以參考阮一峰老師的圖：
Github
專門釋出了一個網站 叫做 Choose an open source license 可以幫助你簡化判斷。
這個網站主張讓開發者從自己的目的出發選擇許可證。詳細如下：
-
需要簡單寬松的協定： MIT 協定
==> 代表項目：
Vue
React
Element
- 比較關心專利：
Apache
協定
==> 代表項目：
Apache
SVN
- 比較關心項目的共享改進:
GPL
Linux
Git
- 非代碼項目：
CCreative Commons
==>署名： 必須提到作者
==>非商業使用者
==>禁止演繹，禁止修改原作品在創作
在 Github 中添加開源許可證
在
Github
中已經添加了各種開源許可證的模版。在建立項目的時候可以直接選擇對應的開源協定。
當然也可以後期添加和修改，下面就在元件庫添加上開源協定。
其實開源許可證就是一個文本檔案放在項目的根目錄下，是以可以在根目錄下點選 【
Add file
】選擇 【
Create new file
】
然後填入檔案名 【
LICENSE
】，
Github
會自動判斷出你需要添加開源協定的，并且會顯示 【
CHoose a license template
】選擇許可證模版按鈕，點選按鈕就可以選擇你需要的模版了。
然後是有效期和作者全名。
- 有效期填寫： 2022
- 作者全名還是有點講究的 可以把你的中文名字和英文名字做一個混合填寫，比如 ： genius
添加完成後，點選
Review and Submit
就可以建立屬于自己的許可證了。
擴充閱讀
- Choose an open source license，https://choosealicense.com/
- MIT License 協定原文 https://opensource.org/licenses/MIT
- Apache License 2.0 協定原文 http://www.apache.org/licenses/LICENSE-2.0.html
- GNU GPL v3 協定原文 https://www.gnu.org/licenses/gpl-3.0.txt
- 更多開源許可清單 https://spdx.org/licenses/
- 主流開源協定之間有何異同？ https://www.zhihu.com/question/19568896
- 《程式員不可不知的版權協定》，作者 GcsSloop https://www.gcssloop.com/tips/choose-license
- 《如何選擇開源許可證？》，作者 阮一峰，http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html