不管產品是免費向公眾分發，還是**，制定乙份許可協議非常有用，否則，對於前者，你相當於放棄了自己所有的權利，任何人都沒有義務表明你的原始作 者身份，對於後者，你將不得不花費比開發更多的精力用來逐個處理使用者的授權問題。
而開源許可協議使這些事情變得簡單，開發者很容易向乙個專案貢獻自己的**，它還可以保護你原始作者的身份，使你 至少獲得認可，開源許可協議還可以阻止其它人將某個產品據為己有。以下是開源界的 5 大許可協議。
gnu general public licence (gpl) 有可能是開源界最常用的許可模式。gpl 保證了所有開發者的權利，同時為使用者提供了足夠的複製，分發，修改的權利：
需要注意的是，分發的時候，需要明確提供源**和二進位制檔案，另外，用於某些程式的某些協議有一些問題和限制，你可以看一下 @pierrejoye 寫的 practical
guide to gpl compliance 一文。使用 gpl 協議，你必須在源****中包含相應資訊，以及協議本身。
gnu lgpl
gnu 還有另外一種協議，叫做 lgpl （lesser
general public licence），它對產品所保留的權利比 gpl 少，總的來說，lgpl 適合那些用於非 gpl 或非開源產品的開源類庫或框架。因為 gpl 要求，使用了 gpl **的產品必須也使用 gpl 協議，開發者不允許將 gpl **用於商業產品。lgpl 繞過了這一限制。
bsd 在軟體分發方面的限制比別的開源協議（如 gnu gpl）要少。該協議有多種版本，最主要的版本有兩個，新 bsd 協議與簡單 bsd 協議，這兩種協議經過修正，都和 gpl 相容，並為開源組織所認可。
mit 協議可能是幾大開源協議中最寬鬆的乙個，核心條款是：
該軟體及其相關文件對所有人免費，可以任意處置，包括使用，複製，修改，合併，發表，分發，再授權，或者銷售。唯一的限制是，軟體中必須包含上述版 權和許可提示。
這意味著：
mit 協議是所有開源許可中最寬鬆的乙個，除了必須包含許可宣告外，再無任何限制。
apache 協議 2.0 和別的開源協議相比，除了為使用者提供版權許可之外，還有專利許可，對於那些涉及專利內容的開發者而言，該協議最適合。
apache 協議還有以下需要說明的地方:
分發**方面包含一些要求，主要是，要在宣告中對參與開發的人給予認可幷包含乙份許可協議原文。
creative commons (cc) 並非嚴格意義上的開源許可，它主要用於設計。creative commons 有多種協議，每種都提供了相應授權模式，cc 協議主要包含 4 種基本形式：
mpl是the mozilla public license的簡寫，是2023年初netscape的mozilla小組為其開源軟體專案設計的軟體許可證。mpl許可證出現的最重要原因就是，netscape公司認為gpl許可證沒有很好地平衡開發者對源**的需求和他們利用源**獲得的利益。同著名的gpl許可證和bsd許可證相比，mpl在許多權利與義務的約定方面與它們相同（因為都是符合osia認定的開源軟體許可證）。但是，相比而言mpl還有以下幾個顯著的不同之處:
qpl是the qt public license的簡稱，是挪威一家機構創設的。qpl許可證的基本要求是獲得源**、修改源**，並可將修改從原始**中分離出來;修改可以按照作者的意願被組合到新版本中;二進位制**可以和原始**同名，這一點對於動態連線庫來說尤其重要;任何人都可以修正錯誤，這對於系統的發布者來說很關鍵;修改過的軟體可以按照滿足qpl許可證基本要求的任何開源軟體許可證進行發布。
qncl許可證是qt non commercial license的簡稱，是qpl許可證的「兄弟版」，就像gpl許可證與lgpl許可證的關係一樣，qncl許可證比qpl許可證更嚴格一些。
在修改和發布方面的規定，qncl許可證與qpl許可證是一樣的，差異就在於軟體的範圍方面，或者說在連線方面。qncl許可證規定「假如乙個應用程式給你提供了乙個入口，使你有權使用qncl許可證下的軟體的功能開發程式、重複使用程式的某一部分或其他軟體的某一部分，那麼對該應用程式的使用視為是使用qncl許可證下的軟體的行為，該應用程式應受到qncl許可證的約束」。qncl許可證比qpl許可證更嚴格之處在於，qncl許可證像gpl許可證那樣，完全禁止根據本許可證得到的開放原始碼軟體與其他非系統庫函式連線的軟體以其他許可方式一起發布。
jabber許可證的全稱是jabber open source license，由美國jabber.com, inc.公司提供。jabber許可證在源**的複製、發行規定方面基本上和其他許可證沒有什麼特別，但有一些細節規定值得借鑑:
common許可證的全稱是common public license。在滿足osia開源軟體許可證認證標準的前提下，common許可證還有一些細節性的規定值得參考:
ibm許可證的全稱是ibm public license。在滿足osia開源軟體許可證認證標準的前提下，ibm許可證還有如下一些細節性規定:
這些許可形式可以結合起來用，其中最嚴厲的組合是「署名，非商用，不能衍生新作品」，意味著，你可以分享作品，但不能改動或以此盈利，而且必須為原
作者署名。在這種許可模式下，原始作者對作品還擁有完全的控制權，而最寬鬆的組合是「署名」，意味著，只要為原始作者署名了，就可以自由處置。
開源協議介紹
mozilla public license bsd開源協議 bsd開源協議是乙個給於使用者很大自由的協議。可以自由的使用，修改源 也可以將修改後的 作為開源或者專有軟體再發布。當你發布使用了bsd協議的 或則以bsd協議 為基礎做二次開發自己的產品時，需要滿足三個條件 1 如果再發布的產品中包含源...
開源協議介紹
一 開源協議介紹 1.1 介紹 apache licene 2.0 協議 apache licence是著名的非盈利開源組織apache採用的協議。該協議和bsd類似，同樣鼓勵 共享和尊重原作者的著作權，同樣允許 修改，再發布 作為開源或商業軟體 需要滿足的條件也和bsd類似 1 需要給 的使用者乙...
筆記 開源協議介紹
在github上建立專案時，系統可以為我們自動新增需要的開源許可證檔案。但是，前提是要知道這些開源協議的區別。一下簡要介紹幾種。apache 2.0 apache licence是著名的非盈利開源組織apache採用的協議。該協議和bsd類似，同樣鼓勵 共享和尊重原作者的著作權，同樣允許 修改，再發...