標籤：

開源許可證都有什麼區別,一般開源項目用什麼許可證?

12-31

平時代碼都不加許可證，因為不是太在意，但是今天突然有老外郵件給我問我要許可證，這個項目用來幹什麼的無所謂，就直接告訴人家隨便用了。這才意識到證書的重要性，而且對於選擇怎樣的證書的確很困惑，不是僅僅限於現在的項目，將來寫的代碼，可能也要別樣的證書呢。

WIKI整理:

GPL:如果有開源強迫症,是個不錯的選擇

MIT:如果沒有特別的要求,這個比較合適

I"ve googled it for you. Hopefully it will help.

對於你這樣的選擇困難症…Github專門發布了一個網站Choosing an OSS license doesn』t need to be scary來幫助開源項目開發者。

1. 我想要一個簡單寬鬆的許可證

建議： MIT許可證。這是一個寬鬆的、簡明扼要的許可證，只要用戶在項目副本中包含了版權聲明和許可聲明，他們就可以拿你的代碼做任何想做的事情，你也無需承擔任何責任。

使用該許可證的項目：jQuery、Rails

2. 我比較關心專利

建議： Apache許可證。這類似於MIT許可證，但它同時還包含了貢獻者向用戶提供專利授權相關的條款。

使用該許可證的項目：Apache、SVN和NuGet

3. 我關心項目的共享改進

建議：GPL（ V2或 V3）許可證。這是一種copyleft許可證，要求修改項目代碼的用戶再次分發源碼或二進位代碼時，必須公布他的相關修改。V3版本與V2類似，但其進一步約束了在某些限制軟體更改的硬體上的使用範圍。

使用該許可證的項目：Linux、Git

4. 我的開源項目不是代碼

建議： Creative Commons。這是一個相對寬鬆的版權協議。它只保留幾種了權利（some rights reserved）。使用者可以明確知道所有者的權利，不容易侵犯對方的版權，作品可以得到有效傳播。

作為作者，你可以選擇以下1~4種權利組合:

1. 署名（Attribution，簡寫為BY）：必須提到原作者。

2. 非商業用途（Noncommercial，簡寫為NC）：不得用於盈利性目的。

3. 禁止演繹（No Derivative Works，簡寫為ND）：不得修改原作品, 不得再創作。

4. 相同方式共享（Share Alike，簡寫為SA）：允許修改原作品，但必須使用相同的許可證發布。

5. 更多選擇

Licenses - ChooseALicense.com，這裡提供了Apache/ GPL/ MIT/ Artistic/ Eclipse/ BSD/ LGPL/ Mozilla/ No License/ Public Domain Dedication協議的適用情形、許可內容、禁止內容，及協議全文。

6. 不使用任何許可

另外，前面答主提到的阮一峰博文」如何選擇開源許可證？「亦可作為簡單參考。

Part of the translation in this passage came from CSDN - Github Open Source License.

如果用到了開源代碼，就應該按照協議進行開源。

根據開源協議百度百科及@劉哇勇 的博文「如何為你的代碼選擇選擇一個開源協議」整理了一下主流開源的開源協議，以及我們改如何選擇。

License是軟體的授權許可，裡面詳盡表述了你獲得代碼後擁有的權利，可以對別人的作品進行何種操作，何種操作又是被禁止的。軟體協議可分為開源和商業兩類，對於商業協議，或者叫法律聲明、許可協議，每個軟體會有自己的一套行文，由軟體作者或專門律師撰寫，對於大多數人來說不必自己花時間和精力去寫繁長的許可協議，選擇一份廣為流傳的開源協議就是個不錯的選擇。

世界上開源軟體協議OPEN SOURCE LICENSE的種類非常之多，並且同一款協議有很多變種，協議太寬鬆會導致作者喪失對作品的很多權利，太嚴格又不便於使用者使用及作品的傳播，所以開源作者要考慮自己對作品想保留哪些權利，放開哪些限制。

一、主流的開源協議

1. GPL

GPL，是GNU General Public License的縮寫，為GNU通用公共授權非正式的中文翻譯。我們很熟悉的Linux就是採用了GPL，GPL協議和BSD, Apache License等鼓勵代碼重用的許可很不一樣，GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用，但不允許修改後和衍生的代碼做為閉源的商業軟體發布和銷售。這也就是為什麼我們能用免費的各種linux，包括商業公司的linux和linux上各種各樣的由個人，組織，以及商業軟體公司開發的免費軟體了。

  • GPL1即最初的版本，發佈於1989年一月，其目的是防止那些阻礙自由軟體的行為，而這些阻礙軟體開源的行為主要有兩種（一種是軟體發布者只發布可執行的二進位代碼而不發布具體源代碼，一種是軟體發布者在軟體許可加入限制性條款）。因此按照GPLv1，如果發布了可執行的二進位代碼，就必須同時發布可讀的源代碼，並且在發布任何基於GPL許可的軟體時，不能添加任何限制性的條款。
  • GPL2在1991年6月發布，與此同時第二個許可證程序庫GNU通用公共許可證（LGPL,the Lesser General Public License）也被發布出來並且一開始就將其版本定為第2版本以表示其和GPLv2的互補性。這個版本一直延續到1999年，並分支出一個派生的LGPL版本號為2.1，並將其重命名為輕量級通用公共許可證（又稱寬通用公共許可證）（Lesser General Public License）以反映其在整個GNU哲學中的位置。
  • GPL3正由斯托曼起草，由伊本·莫格林和軟體自由法律中心（Software Freedom Law Center） 提供法律諮詢。斯托曼在2006年2月25日自由及開源軟體開發者歐洲會議的演講上說在所有的改動中，最重要的四個是：解決軟體專利問題；與其他許可證的兼容性；源代碼分區和組成的定義；解決數位版權管理（DRM）問題。

GPL協議的主要內容是只要在一個軟體中使用(「使用」指類庫引用，修改後的代碼或者衍生代碼)GPL 協議的產品，則該軟體產品必須也採用GPL協議，即必須也是開源和免費，這就是所謂的」傳染性」。GPL協議的產品作為一個單獨的產品使用沒有任何問題，還可以享受免費的優勢，由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議，對於使用GPL協議的開源代碼，商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。

2. BSD

BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以」為所欲為」,可以自由的使用，修改源代碼，也可以將修改後的代碼作為開源或者專有軟體再發布。但」為所欲為」的前提當你發布使用了BSD協議的代碼，或則以BSD協議代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

  • 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的BSD協議。
  • 如果再發布的只是二進位類庫/軟體，則需要在類庫/軟體的文檔和版權聲明中包含原來代碼中的BSD協議。
  • 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 代碼鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發布代碼，也允許使用或在BSD代碼上開發商業軟體發布和銷售，因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

3. MIT

MIT許可證之名源自麻省理工學院（Massachusetts Institute of Technology, MIT），又稱「X條款」（X License）或「X11條款」（X11 License），是一份簡短而寬鬆的協議，只提供了版權保護和聲明，它授予他人複製，修改，合併，發布，分發，授權和/或銷售本軟體的副本的權力，被授權人可根據程序的需要修改授權條款為適當的內容。作者只想保留版權，而無任何其他了限制，也就是說必須在發行版里包含原許可協議的聲明，無論以二進位發布的還是以源代碼發布。

4. MPL

MPL是The Mozilla Public License的簡寫，是1998年初Netscape的 Mozilla小組為其開源軟體項目設計的軟體許可證。MPL許可證出現的最重要原因就是，Netscape公司認為GPL許可證沒有很好地平衡開發者對源代碼的需求和他們利用源代碼獲得的利益，同著名的GPL許可證和BSD許可證相比，MPL在許多權利與義務的約定方面與它們相同。（因為都是符合OSIA認定的開源軟體許可證）。但是，相比而言MPL還有以下幾個顯著的不同之處:

  • MPL雖然要求對於經MPL許可證發布的源代碼的修改也要以MPL許可證的方式再許可出來，以保證其他人可以在MPL的條款下共享源代碼。但是，在MPL許可證中對「發布」的定義是「以源代碼方式發布的文件」，這就意味著MPL允許一個企業在自己已有的源代碼庫上加一個介面，除了介面程序的源代碼以MPL許可證的形式對外許可外，源代碼庫中的源代碼就可以不用MPL許可證的方式強制對外許可。這些，就為借鑒別人的源代碼用做自己商業軟體開發的行為留了一個豁口。
  • MPL許可證第三條第7款中允許被許可人將經過MPL許可證獲得的源代碼同自己其他類型的代碼混合得到自己的軟體程序。
  • 對軟體專利的態度，MPL許可證不像GPL許可證那樣明確表示反對軟體專利，但是卻明確要求源代碼的提供者不能提供已經受專利保護的源代碼（除非他本人是專利權人，並書面向公眾免費許可這些源代碼），也不能在將這些源代碼以開放源代碼許可證形式許可後再去申請與這些源代碼有關的專利。
  • 對源代碼的定義。在MPL（1.1版本）許可證中，對源代碼的定義是:「源代碼指的是對作品進行修改最優先擇取的形式，它包括:所有模塊的所有源程序，加上有關的介面的定義，加上控制可執行作品的安裝和編譯的『原本』（原文為『Script』），或者不是與初始源代碼顯著不同的源代碼就是被源代碼貢獻者選擇的從公共領域可以得到的程序代碼。」
  • MPL許可證第3條有專門的一款是關於對源代碼修改進行描述的規定，就是要求所有再發布者都得有一個專門的文件就對源代碼程序修改的時間和修改的方式有描述。

5. Apache License 2.0

Apache License是著名的非盈利開源組織Apache採用的協議，該協議和BSD類似，同樣鼓勵代碼共享和尊重原作者的著作權，同樣允許代碼修改，再發布（作為開源或商業軟體）。需要滿足的條件也和BSD類似：

  • 需要給代碼的用戶一份Apache License。
  • 如果你修改了代碼，需要再被修改的文件中說明。
  • 在延伸的代碼中（修改和有源代碼衍生的代碼中）需要帶有原來代碼中的協議，商標，專利聲明和其他原來作者規定需要包含的說明。
  • 如果再發布的產品中包含一個Notice文件，則在Notice文件中需要帶有Apache License。你可以在Notice中增加自己的許可，但不可以表現為對Apache License構成更改。

Apache License也是對商業應用友好的許可，使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發布/銷售。

6. LGPL

LGPL（亦稱GPL V2）是GPL的一個為主要為類庫使用設計的開源協議，和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協議不同。LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。這使得採用LGPL協議的開源代碼可以被商業軟體作為類庫引用並發布和銷售。

但是如果修改LGPL協議的代碼或者衍生，則所有修改的代碼，涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟體引用，但不適合希望以LGPL協議代碼為基礎，通過修改和衍生的方式做二次開發的商業軟體採用。GPL/LGPL都保障原作者的知識產權，避免有人利用開源代碼複製並開發類似的產品。

二、選擇適合自己的開源協議

烏克蘭程序員Paul Bagwell，畫了一張分析圖，介紹最流行的六種開源許可證GPL、BSD、MIT、MPL、Apache和LGPL下圖為國內大牛阮一峰漢化了版本。

1. 簡單寬鬆的協議

如果你怕麻煩只想要一個簡單協議，MIT協議相對寬鬆但抓住了要點，此協議允許別人以任何方式使用你的代碼同時署名原作者，但原作者不承擔代碼使用後的風險，當然也沒有技術支持的義務，jQuery和Rails就是MIT協議。

2. 有專利的需求

如果你的作品中涉及到專利相關，Apache協議也是個相對寬鬆與MIT類似的協議，但它簡單指明了作品歸屬者的著作權，Apache伺服器，SVN還有NuGet等是使用的Apache協議。

3. 代碼分享與促進

如果你在乎作品的傳播和別人的修改，希望別人也以相同的協議分享出來。GPL（V2或V3）是一種版本自由的協議（可以參照copy right來理解，後者是版本保留，那copyleft便是版權自由，或者無版權，但無版權不代表你可以不遵守軟體中聲明的協議）。此協議要求代碼分發者或者以此代碼為基礎開發出來的衍生作品需要以同樣的協議來發布。

4. 主流協議授權詳情

看完以上信息，你是否對主流的開源協議和如何為自己的開源項目選擇合適的協議有了一定的了解呢？希望當每一位開源作者的項目被侵權時都能積極維護自身的權利，也希望大家更「合法」的應用開源項目，創造一個良好的開源環境。

開源不等於免費，開源也不等於沒有約束。

原文鏈接：如何為你的代碼選擇一個開源協議 - 劉哇勇 - 博客園

來碼雲 http://Gitee.com

發現更多優質開源項目：最新推薦 - 碼雲 - 開源中國

讓團隊流暢、高效開發：碼雲企業版 - 碼雲 - 開源中國

WTFPL

好久沒回答問題了，好不容易碰到個可以幫忙解答的就不請自來了~~

=Start=

世界上的開源許可證，在GNU的網站上有記錄的就有好多種。

但很少有人搞得清楚它們的區別。現在最流行應該是——GPL、BSD、MIT、Mozilla、Apache和LGPL。

烏克蘭程序員Paul Bagwell，畫了一張分析圖，說明應該怎麼選擇。

個人非常敬佩的阮一峰也專門寫了篇博文：如何選擇開源許可證？

還有譯言網的：譯言網 | 開源類軟體許可證簡明指南

以及在阮一峰的博客文章評論區中看到的：如何選擇開源許可證？

總結下來大概就是：要麼直接將代碼開源，不帶任何許可證，這個是最開放的；除此之外MIT應該算是最開放的開源許可證了（也有少許限制），其它的或多或少都有更多的限制。

=End=

還請批評指正，謝謝。

。。。瀉藥。。。

證書是啥。。。你是說協議吧。。。

常見的開源協議可以 Google 一下對比。。。我手機打字不方便。。。

常用的好像就是 GPL 系列，BSD，Apache 和 MIT 了吧。。。

其他的還有 你他媽愛幹啥就幹啥 這種奇葩協議。。。

起床用電腦再填。。。

開源協議通俗介紹

TLDRLegal - Software Licenses Explained in Plain English

如何選擇開源許可證？

推薦閱讀：

※OIer對於開源的態度如何？
※C++後台開發有哪些練基礎的開源項目？
※如何看待 Github Gist 這個服務，怎樣更好的利用？
※如果蘋果忽然宣布 iOS 開源，這個世界會發生什麼？

TAG:開源軟體 | 開源 | 開源項目 |