選自choosealicense
機器之心編譯
參與：Panda W
沒有開源證書，開源軟件和代碼就沒有相應的保護，可是 MIT 證書、Apache 證書之類的有什麼區別呢？這篇文章教你為自己的項目選擇合適的證書。
在我們現在所處的這個被軟件和數字化內容包圍的時代，開源證書具有極其重要的價值和意義。但你知道如何為你的項目或工作選擇合適的開源證書嗎？choosealicense.com 就是為這一任務而生的，能輔助你找到最適合的開源證書。本文總結該網站上的部分內容，介紹了選取開源證書的方式以及部分證書的授權內容，最後還談到了對於無證書的情況的應對方法。 開源證書可以保護貢獻者和用戶。企業和精明的開發者不會觸碰沒有這種保護的項目。
已有的項目和社區 如果你在為一個已有的項目做貢獻或做擴展，最簡單的方法就是繼續使用該項目的證書。要查找這個證書，只需尋找一個名叫 LICENSE 或 COPYING 的文件，另外還要瀏覽一下 README。如果你無法找到證書，可以詢問項目維護者。 不同的項目有不同的偏好。對於某些項目而言，使用原項目的證書不僅是因為這樣做最簡單，而且還是原項目證書規定的一項要求。參見某些證書的「同一證書（same license）」條款。
某些社區非常偏好特定的證書。如果你想要參與其中某個社區，即使當你決定發起一個新項目而且不依賴已有項目時，使用他們偏好的證書會更輕鬆一些。下面給出一些例子：
- Apache 需要 Apache License 2.0 證書
- Cloud Native Computing Foundation（雲原生計算基金會）默認指定了 Apache License 2.0 證書
- GNU 建議大多數程序使用 GNU GPLv3 證書
- NPM 軟件包大都使用 MIT 證書或非常相似的 ISC 證書
- OpenBSD 更偏好 ISC 證書
- Rust crates 大都使用了 MIT 和 Apache License 2.0 證書
- WordPress 插件和主題必須使用 GNU GPLv2（或更新的）證書
社區有各種各樣的類型和規模，而且多個社區之間還可能存在關聯（如果你在某家公司工作，還要注意公司的法律要求）。上面給出的例子都是已經很完善的社區。如果你正在構建項目的社區還沒有固定的證書傳統，或者你並不認為你的項目屬於某個特定的社區，也沒有問題：你需要選擇自己的開源證書。下面簡單介紹幾種開源證書。 MIT 證書 這是一個簡短的許可證，其條款中僅要求保留版權和許可聲明。使用該證書的工作、修改和更大型的成果可能會以不同的條款進行分發，也可以不分發源代碼。
GNU 許可證 v3.0 GNU 許可證 v3.0 按不同強度 copyleft 許可權限分為三級，分別是最強的 GNU Affero General Public License v3.0（GNU AGPLv3）、GNU General Public License v3.0（GNU GPLv3）和 GNU Lesser General Public License v3.0（GNU LGPLv3）。 首先，我們先看看 copyleft 許可強度居中的 GNU GPLv3：這是一種強 copyleft 的許可證，其條件是提供使用該證書的工作和修改的完整源代碼，這包括：使用了已有該證書的工作的更大型工作也要使用同一證書。版權和許可聲明必須保留。貢獻者需明確提供專利權授權。
對於 copyleft 強度更高的 GNU AGPLv3，其要求在使用經過修改的該許可授權的代碼在網絡上提供服務時，同時也必須公開該服務所用的修改版的完整源代碼。 而對於 copyleft 強度更低的 GNU LGPLv3，其許可：當通過接口方式提供已有該許可證的軟件時，更大型的工作可以基於不同的條款分發，也無需提供該更大型工作的源代碼。 除此之外，軟件項目常用的開源證書還有 Mozilla Public License 2.0、Apache License 2.0、Boost Software License 1.0、The Unlicense 等，它們都有各自不同的許可權限範圍以及要求。
非軟件證書 除了用於開源軟件項目的證書之外，也有針對非軟件工作的證書。當然，開源軟件證書基本也都可以用於非軟件的工作，而且也往往也是最好的選擇，尤其是當證書許可的工作是可以編輯或製作不同的版本時（比如開源硬件設計）。下面介紹一些針對不同類型的非軟件工作的證書： 數據、媒體內容等 CC0-1.0、CC-BY-4.0 、CC-BY-SA-4.0 是可用於從數據集到視頻等非軟件材料的開放證書。注意，CC-BY-4.0 和 CC-BY-SA-4.0 不應該用於軟件。 文檔 任何開源軟件證書或用於媒體內容的開放證書都可用於軟件文檔。如果你為你的軟件和文檔使用不同的證書，一定要確保文檔中給出的源代碼示例是用軟件證書授權的。
如果你的項目包含軟件和其它材料，你可以包含多個證書，只要你明確指定哪個證書適用於該項目的哪些部分。
不使用證書
當你在做一項創意工作（包括代碼）時，該工作默認是有專屬版本的。除非你使用一個證書明確說明許可權限，那麼其他人都不能複製、分發或修改你的工作，因為這可能面臨著被下架、索賠和起訴的風險。如果該工作還有其他貢獻者（每個人都是一個版權所有者），那麼就沒人能用它了，包括你自己。
即使在缺少證書文件時，你也可能會授予一些權限，因為當你在某些網站上發佈源代碼時需要接受一些服務條款。舉個例子，如果你在 GitHub 的一個公共庫中發佈你的源代碼，那麼你就接受了該網站的服務條款，也就是說你允許其他用戶查看和分叉你的庫。如果在特定情況中使用了版權限制和例外，那麼其他人可能還需要你的許可。但是，不管是網站服務條款還是法律指定的版權限制，都不足以支持人們希望在公共代碼託管方面所尋求的合作，比如開源證書所提供的那種實驗、修改和共享授權。
不提供證書完全無需任何操作。但是，你也許需要在顯眼的位置（比如 README）添加一個版權注意和聲明，表明你不提供任何證書，這樣用戶就不會認為你忽視了這一點。如果你希望在你的無證書項目中接受其他人的貢獻，你可能還需要和你的律師談談，添加一個貢獻者聲明，以便你能夠維護來自貢獻者的版權許可，即便你並不提供同樣的權限。
你選擇「無證書」的意圖可能並不是禁止人們使用你的代碼。有的開源證書允許人們在使用你的代碼時維持你的版權。如果你的目標是完全拋棄版權限制，那麼試試公共領域專用的證書：The Unlicense
用戶該如何應對無證書的情況？
如果你發現某個軟件沒有證書，那麼這通常意味著你無權使用、修改和共享該軟件。儘管 GitHub 上的代碼託管可能讓你可以查看和分叉代碼，但這並不意味著你有權以任何目的使用、修改和共享該軟件。
你有如下選擇：
- 懇請維護者添加一個證書。除非該軟件明確說明不允許使用，否則缺少證書多半是因為疏忽。如果該軟件託管在 GitHub 這樣的網站上，那麼可以開一個問題，要求其提供一個證書。如果你膽子夠大，而且你知道什麼證書是最合適的，那麼可以提出一個 pull 請求來添加證書。
- 不要使用這個軟件。尋找或創建有開源證書的替代軟件。
- 協商獲取私人授權。叫上你的律師。
參考鏈接：
https://choosealicense.com/
https://github.com/github/choosealicense.com
閱讀更多 機器之心Pro 的文章
