文章出處

相信很多剛踏入軟件這個行業的小伙伴一如當初的我，對開源軟件的各種協議不甚了解被搞昏了頭腦。畢竟對于一個新生程序員來說，如何寫好代碼才是亟待解決的問題，無暇了解這些。隨著你項目做得多了代碼寫得多了，你會發現編碼過程中會不時用到其他人的成果，一個項目下來多少會引入一些優秀的庫，別人放在公網上開源的DLL，以及一些算法等等。細心的你會注意到即使只是一小段代碼，優秀的作者都在最開始會簡單地附上一段關于許可的聲明，或者說是協議比如"Licensed under the MIT license"，并且一些博客也會標明"此文章發表在CC協議下"。而如果我們Copy了別人的代碼或者文字同時沒注意這些的話，在國外法律意識特別強的環境下，我們的作品會因觸犯別人的權益而違法。因為好多開源協議最低要求是使用者需要保留原作者對代碼的聲明，不聲不響地就拿來用了必然導致惡果。

所以開源不等于免費，開源也不等于沒有約束。

何為License

License是軟件的授權許可，里面詳盡表述了你獲得代碼后擁有的權利，可以對別人的作品進行何種操作，何種操作又是被禁止的。軟件協議可分為開源和商業。當然本文要討論的當然是開源協議。

對于商業協議，或者叫法律聲明、許可協議，每個軟件會有自己的一套行文，由軟件作者或專門律師撰寫。這是什么驚為天人的東西嘛還得請專門的律師。因為涉及到以后侵權打官司這種事情，這種商業條款的行文是非常嚴謹而講究的，記得以前看到句調侃的話：'如果法律文件不寫得那么生澀難懂，律師們就沒飯吃了'，就是說任何文字一旦上升到法律的層次，不要說你接受完了九年義務教育，就是考了個專八也會覺得英語白學了，直接的法律協議什么的那不是給常人看的。而至于法律條款緣何會晦澀難懂，這個偏題有點偏遠了，可以查看這里了解。看累了？下面是歡樂時刻，奉上一個協議相關的Joke（笑崩！蘋果iOS7升級協議條款中員工神吐槽）。

你丫知道么？這已經是46頁，肯定沒人讀的。我敢打賭大概只有5個人點了"條款和協議"，所以我們想扯點啥就扯點啥吧。

Apple總部5樓的那個tony總是渾身一股沙丁魚味

有人給我們寄點啥2b向的郵件，我們都得很文藝的用"i笑了"的方式回復。這是我們的工作規定

還記得當年關于Apple Studio的版權合法性爭議么？想知道我們怎么擺平的？我們把披頭士樂隊買下來了。他們中活著的現在沒事來給我們唱兩曲解解悶，死了的，我們想辦法像Miku的3D投影那樣，設法在二次元給他們來個復活

我們餐廳永遠只賣蘋果東西：蘋果，蘋果汁，蘋果煎餅，蘋果棒糖。。。不想丟工作的話我們只能吃這些，而哥恰好對蘋果過敏，哥現在正處于餓的神志不清亂敲鍵盤的節奏。

我們偽造了登月真相。其實美國人登月是2008年的事情，我們向你們洗腦它發生在1969，我們絕對有這種洗腦的本事。如果有人發現我知道的太多了，我就會被查水表，但是沒關系，沒人會看這頁。

所以對于大多數人來說，不用自己花大把時間去寫許可協議，選擇一分廣為流傳的開源協議是個不錯的選擇，如果你的作品是開源的話，這樣省時又省心。

選擇一分協議的好處

你的作品如果不是定性為全商業性質，可以考慮選擇一分流行度比較高的開源協議。具體來說的話，你肯定希望作品能夠被多數人分享查閱吧，不但提高自己業界的知名度，同時也方便了需要的人為開源做出了貢獻。換句話說，你不分享出來的話你的作品的意義何在呢（當然，自己搗騰的私人東西還是自己保留吧）？可是一旦你把你的代碼貼出來，這就表示任何人都可以看到并獲取，之后發生的事情你無法控制，有的人或許稍微修改一下放進自己的代碼中，有的把你的軟件改個名字拿去販賣，有的甚至會拿去把作者名字改為自己然后拿去找工作什么的，而不會有人知道這個作品的原作者，背后辛勤付出了的人。所以為了公開分享你的代碼，同時又讓你對代碼保留一定權利，在作品中聲明一個許可協議是非常有必要的，這是很多新人所忽略的問題，同時很多人在使用別人的勞動成果時也會忽視協議的存在，這樣不好。所以你會看到我的博客里面時不時會給出連接指向來源頁面，同時文末也會列出所有參考過的文章。我相信我做到了這點，別人在轉載我的文章的時候，也可以做到這點，這樣營造出來的氛圍一定會非常和諧，互相尊重/Show Respect。

多說一句，一個事實讓你了解國外開發者在尊重他人勞動成果方面做得是如何的到位，如果A的作品是因為B的作品的啟發而來，A甚至都沒有使用B任何一句代碼，但A會在他的作品里面指明是受到了B的啟發"Inspired by XXX link :http://www.blah.com"。

當然有人會覺得，有了一分協議聲明在那里，我就需要鳥你么，我拿來用了把作者名字去掉同時還要加上我的名字，你咬我？！這是后話，只是在利益很小的情況下，或者作者不知情的情況下，作者不會追究什么責任，但如果你的產品做成功了，那就不一定了。另外就是，有協議和沒聲明協議的裸代碼是有非常重要區別的，一般作品當中沒聲明協議的默認為Copy right的，也就是版權保留。此種情況表明他人沒有任何授權，不得復制分發修改使用等等，但一如上面所討論的，這樣的話還何來開源，何來分享呢。有了協議的聲明，在未來你的維權上面會方便很多，讓你的作品在分享的同時保留了自身的一些權利。

快速選擇

目前流行的開源協議有很多，并且同一款協議有很多變種，比如你或許看到過' CC Attribution-NoDerivs',' CC Attribution-NonCommercial'同屬CC協議（后面會有介紹）。如此紛繁的協議該如何選擇？協議太寬松會導致作者喪失對作品的很多權利，太嚴格又不便于使用者使用及作品的傳播。所以除了協議多之外，你還要考慮你對作品想保留哪些權利，放開哪些限制。

如果你不想了解太多，只是想要一個簡直直接的答案，下面給出的建議或許適合你。下方關于協議的選擇及表格來自GitHub choosealicence項目。

簡單寬松的協議

如果你只想要一個簡單點的協議不想太麻煩的話。

MIT協議相對寬松但還是抓住了要點的。此協議允許別人以任何方式使用你的代碼同時署名原作者，但原作者不承擔代碼使用后的風險，當然也沒有技術支持的義務。jQuery和Rails就是MIT協議。

考慮有專利的情況

如果你的作品中涉及到專利相關。

Apache協議也是個相對寬松與MIT類似的協議，但它簡單指明了作品歸屬者對用戶專利上的一些授權（我的理解是軟件作品中含有專利，但它授權你可以免費使用）。Apache服務器，SVN還有NuGet等是使用的Apache協議。

代碼分享與促進

如果你在乎作品的傳播和別人的修改，希望別人也以相同的協議分享出來。

GPL（V2或V3）是一種版本自由的協議（可以參照copy right來理解，后者是版本保留，那copyleft便是版權自由，或者無版權，但無版權不代表你可以不遵守軟件中聲明的協議）。此協議要求代碼分發者或者以此代碼為基礎開發出來的衍生作品需要以同樣的協議來發布。此協議的版本3與版本2相近，只是多3中加了條對于不支持修改后代碼運行的硬件的限制（沒太明白此句話的內涵）。

各協議授權詳情

下面是更多開源協議的一個表格任君選擇，總有一款是你的菜。

不過先來了解一些下方表格中出現的用詞的解釋：

協議和版權信息(License and copyright notice)：在代碼中保留作者提供的協議和版權信息
聲明變更(State Changes)：在代碼中聲明對原來代碼的重大修改及變更
公開源碼(Disclose Source)：代碼必需公開。如果是基于LGPL協議下，則只需使用的開源代碼公開，不必將整個軟件源碼公開
庫引用(Library usage)：該庫可以用于商業軟件中
責任承擔(Hold Liable)：代碼的作者承擔代碼使用后的風險及產生的后果
商標使用(Use Trademark)：可以使用作者的姓名，作品的Logo，或商標
附加協議(Sublicensing)：允許在軟件分發傳播過程中附加上原來沒有的協議條款等

協議	描述	要求	允許	禁止
Apache	一個較寬松且簡明地指出了專利授權的協議。	協議和版權信息聲明變更	商用分發修改專利授權私用附加協議	責任承擔（禁止讓作者承擔責任，可以理解為免責）商標使用
GPL	此協議是應用最為廣泛的開源協議，擁有較強的版權自由( copyleft )要求。衍生代碼的分發需開源并且也要遵守此協議。此協議有許多變種，不同變種的要求略有不同。	公開源碼協議和版權信息聲明變更	商用分發修改專利授權私用	責任承擔附加協議
MIT	寬松簡單且精要的一個協議。在適當標明來源及免責的情況下，它允許你對代碼進行任何形式的使用。	協議和版權信息	商用分發修改私用附加協議	責任承擔
Artistic	Perl社區尤為鐘愛此協議。要求更改后的軟件不能影響原軟件的使用。	協議和版權信息聲明變更	商用分發修改私用附加協議	責任承擔商標使用
BSD	較為寬松的協議，包含兩個變種BSD 2-Clause 和BSD 3-Clause，兩者都與MIT協議只存在細微差異。	協議和版權信息	商用分發修改私用附加協議	責任承擔
Eclipse	對商用非常友好的一種協議，可以用于軟件的商業授權。包含對專利的優雅授權，并且也可以對相關代碼應用商業協議。	公開源碼協議和版權信息	商用分發修改專利授權私用附加協議	責任承擔
LGPL	主要用于一些代碼庫。衍生代碼可以以此協議發布（言下之意你可以用其他協議），但與此協議相關的代碼必需遵循此協議。	公開源碼庫引用協議和版權信息	商用分發修改專利授權私用附加協議	責任承擔
Mozilla	Mozilla Public License(MPL 2.0)是由Mozilla基金創建維護的。此協議旨在較為寬松的BSD協議和更加互惠的GPL協議中尋找一個折衷點。	公開源碼協議和版權信息	商用分發修改專利授權私用附加協議	責任承擔商標使用
No license	你保留所有權利，不允許他人分發，復制或者創造衍生物。當你將代碼發表在一些網站上時需要遵守該網站的協議，此協議可能包含了一些對你勞動成果的授權許可。比如你將代碼發布到GitHub，那么你就必需同意別人可以查看和Fork你的代碼。	協議和版權信息	商用私用	分發修改附加協議
Public domain dedication	在許多國家，默認版權歸作者自動擁有，所以Unlicense協議提供了一種通用的模板，此協議表明你放棄版權，將勞動成果無私貢獻出來。你將喪失對作品的全部權利，包括在MIT/X11中定義的無擔保權利。	N/A	商用分發修改私用	責任承擔

非代碼類作品的協議

上面各協議只是針對軟件或代碼作品，如果你的作品不是代碼，比如視頻，音樂，圖片，文章等，共享于公眾之前，也最好聲明一下協議以保證自己的權益不被侵犯。針對非代碼的數字作品的協議，最通用的莫過于Creative Commons(也是你經常在別人博客下面可以看到的CC協議)協議。所以現在你見到博客園別人文章下面的簽名就不會感到陌生了。