擔心程式碼遭到他人濫用嗎？在發佈更新的時候，很怕合作團隊的系統爛掉嗎？開源專案常出現的 LICENSE 和 CHANGELOG，目的和用途是什麼呢？
本篇筆記，針對不論 前端(Front-end)、後端(Back-end) 或 DevOps 的工程師，都需要了解的「軟體授權」、「語意化版本控制」章節，在 104 職場導師的導讀後，整理而成。
此外，本篇涉及些微的 Github 內容，
可參考 為你自己學 Git 的網頁內容 (與出版書籍相同)。
軟體授權條款 (Licenses)
身為開發人員，我們都知道程式碼跟寫書一樣，是絞盡腦汁的產出，每個人都該擁有自己的著作權。所以，開發時，要注意軟體的授權規範！
對於沒有明確授權條款的公司，或者自己想要耕耘的專案，開發人員要如何選擇，來保障自己的智慧財產權呢？開源組織認可的授權條款就有幾十種，如果已經有明確的需求，可以參考 Github 整理的總表，根據自己的狀況選擇。不然也可以從入口網站，一步步分析專案的類型。
如果要確保公司就算公開程式碼，保有程式碼的所有權益，可以把下面這句直接放在 LICENSE 的檔案中 (實際範例)。
Copyright (c) [year] [name of copyright owner] All Rights Reserved.然而，如果要把第三方的工具用在商用軟體的開發，千萬要注意 LICENSE 的內容，有些規範會規定要承襲一樣的授權條款，因此就不建議使用包含以下授權條款的開源軟體：GNU General Public License(GPL)、Affero GPL。
此外筆者提醒採用常用規範的開發人員，要記得找到條款簽署的地方 (如下圖)，寫上自己或公司的名字，才具有完整的法律效力喔！
關於程式碼的智慧財產權，其實不只是完整使用軟體才算，
如果是複製貼上別人的程式碼，記得在註解處說明！ (如下圖)
語意化版本控制 (Semantic Versioning)
良好的語意化版本控制，可以讓引用的人，清楚知道你開發的功能是否被修改或移除，而能夠決定是要拒絕更新，或者配合新版本，修正程式碼。
根據語意化版本 2.0.0 的規範，版本格式包含三個部分：主版號.次版號.修訂號，如果有其他版本相關資訊也可以加到「主版號.次版號.修訂號」的後面，例如：1.0.0-alpha、1.0.0-alpha.1、1.0.0–0.3.7。
版號遞增的時機點如下
主版號 (major)：當你做了不相容的 API 修改。
次版號 (minor)：當你做了向下相容的功能性新增。
修訂號 (patch)：當你做了向下相容的問題修正。
- 向下相容: 是指每個舊版本支援的功能，新版本也可以用相同的方式呼叫，並做出一樣的事。所以使用者不用修正任何程式碼，更新後仍可以繼續使用。
^ 與 ~ 的用法，還有 x 跟 *
由於筆者最近在鑽研 JavaScript，發現 npm package 會在版號之前出現波浪或著倒勾，這兩者分別代表安裝時接受的版號更新，波浪 ~ 代表容許修訂號不同，倒勾 ^ 代表容許次版號不同，如果是產品用的原始碼，可以刪掉這些前綴符號，確保測試人員或使用者 library 環境一樣！
版本控制的歷史，有些被寫在 Changelog 檔案，又有些放在 Github 的 releases 裡頭。到底該選擇哪個好？
答案是都可以，各有利弊。前者的好處是其他開發者 clone 下來就看得到，不擔心會找不到；後者的好處是有 Github 的圖形化支援 (如下圖)，編修也不用 commit。所以不怕麻煩的話，可以都使用，像是 AWS SDK 的做法。
額外補充，更新日誌 (Changelog) 的撰寫規則，可以參考這篇：如何維護更新日誌 — 更新日誌絕對不應該只是 git log 的堆砌物。
