當你決定把代碼開源之前先選擇一個合適的 License

01-27

這幾天同事 @LeoAshin 折騰了一個自己的博客，問我選擇什麼協議。這讓我想起了之前我遇到的 2 件事。

第一件事發生在知乎，當時有人邀請我回答一個問題：開源 App 被人抄襲到 iOS App Store 怎麼辦？

事情的經過大概是，@coderyi 開發了一款開源播放器 ElevenPlayer，並於去年 9 月 21 日在 App Store 上架，沒想到被 7 個人「抄襲」，功能與視覺上幾乎一樣，一個總榜 70 名，還一個是付費分類榜 21 名。

對於此種情況，大多數同學都是聲援的態度。由於之前我也在各大網路平台聲討過種種抄襲盜版事件，這次自然也要去支援一下。但是當我去看了作者在 github 開源的代碼後，又有些犯難了。

於是我在知乎寫道：

說點作者不愛聽的。
代碼最初使用了 MIT License，這應該是對使用者限制最少的協議了吧。使用者可以閉源分發，可以將代碼商用。前提是只需要附帶一份原協議。
但是別人如果推廣的好，或者修改的好，原作者有可能不會從中收益。
我看了作者的代碼庫，也看了代碼提交歷史，其中好幾條注釋為：「由於某些原因作品從 MIT 協議改變成採用 CC Attribution-NonCommercial 中文：署名-非商業性使用協議」。看來作者也意識到問題了，臨時修改了協議，然而並沒有什麼卵用了，因為開發者依然可以在之前代碼基礎上進行二次開發。
所以啊：選擇開源協議要謹慎。
大家還記得 MacOS 和 BSD 的歷史嗎？
蘋果公司看到 BSD 這麼優秀的開源系統後，眼前一亮：
源碼可以改。
可以閉源。
好，那我就閉源。

可以商用。
哇，正合我意。
最氣人的是，改完的 MacOS 比 BSD 還漂亮、還好用。
這 TM 就尷尬了。
這 TM 就尷尬了。
這 TM 就尷尬了。

那讓我們回過頭來再看看作者開發的這款軟體，是百分之百原創嗎？很顯然不是，作者使用了 ffmpeg、kxmovie、YiRefresh 等開源代碼，由於我沒有下載安裝作者的這個 APP，也就不評價作者有沒有按照開源協議去使用這些開源代碼。但是從作者文中體現出來的開源認知水平來看，作者應該「違規」使用了這些開源代碼。

那我在上文中提到的 MIT License 到底是什麼呢？

License 就是版權許可證，裡面詳盡表述了你獲得代碼後擁有的權利，可以對別人的作品進行何種操作，何種操作又是被禁止的。我們常用的開源軟體協議大致有GPL、BSD、MIT、Mozilla、Apache 和 LGPL。

那麼到底該選擇哪一個 License 呢？烏克蘭程序員 Paul Bagwell 畫了一張分析圖（下圖為阮一峰漢化版）

還有一張更全面並略帶惡搞性質的圖片，由 diycode 社區的 @flniu 進行漢化：

第二件事發生在 v2ex 社區，帖子標題為：竟然有人直接複製我代碼，而不 fork 的！。

看到這個標題我就懵了——難道不可以嗎！！？？（黑人問號.jpg）

之前開發的親戚關係計算器竟然讓人直接拷走…… 簡直無語了，開源就可以隨便來么？直接代碼拷走，放自己倉庫就成自己的了。。。。

？？？？

難道不是嗎？！

關鍵是！為什麼唯一的一個提交顯示的是我提交的？可界面顯示確實不是 fork 我的，難道 github 出錯了，fork 會斷掉關係嗎？

作者開發的「親戚關係計算器」確實不錯，我也用過。對於這種開發者我們應該敬佩。但是作者的言論卻暴露了自己根本不懂開源。誠然，作者選擇把自己的代碼放到 github 或者其他開源社區，當別人 star 或者 fork 了自己的代碼，作者也會為自己的努力感到欣慰。

哪個所謂的「抄襲者」到底錯在哪裡了？答案是，沒有任何錯誤。

「抄襲者」並沒有篡改原作者的任何 commit 記錄，LICENSE 和版權信息也絲毫沒動。

很多人以為在 github 上開源代碼就是在推廣自己了，當發現別人用自己的代碼做的事情比自己還好，就又心裡不平衡了。他們把自己的代碼放到 github 等待別人 star，等待別人 fork，但是當別人使用了代碼卻沒有 fork 時，心裡又不平衡了。

所以做開源，先擺好心態。

每周推送原創高質量文章，歡迎關注我的公眾號