社區時常為流行產品中有爭議的開源許可證而感到震驚，這引起各方關注，紛紛爭論何為真正的開源許可證。去年，Apache 基金會（Apache Foundation）禁止使用 Facebook React 那些具有爭議的專利組件，這引發了軒然大波，并讓大量人員紛紛跑去加入 Reddit boards。在過去的幾個月中， redis Labs 和 MongoDB 修改了他們備受歡迎的開源數據庫的許可證，這讓許多人難以自拔，凸顯了用大家都能看懂的人話來具體介紹常見開源許可證的緊迫性和必要性。
最簡單的解釋是，開源許可證（open source licenses）是軟件組件（software component）的作者與用戶之間的具有法律約束力的合同（legal and binding contracts），聲明該軟件可以在指定條件下（under specified conditions）用于商業應用（be used in commercial Applications）。許可證使得代碼變為開源組件。沒有開源許可證，便無法將該軟件組件給他人使用，即便該組件公開發布于 GitHub。
每個開源許可證都會聲明用戶被允許使用該軟件組件用于何用途、義務、以及條款規定的不可用于哪些用途。這聽起來似乎很簡單，但開源許可證存在至少 200 個——祝你好運，希望你能搞懂它們。由于復雜性和不同要求，組織需要選擇哪些許可證以便與它們的政策最兼容，確保合規。
Copyleft 與 Permissive
兩種類型的開源許可證
開源許可證的兩個主要類別需要深入說明，開源許可證分類兩大類：copyleft 和 permissive，該劃分基于許可證對于用戶的要求與限制（requirements and restrictions）。
版權（Copyright）是一種法律，它賦予了版權所有者限制他人使用、修改與共享創意作品的權利，使用者要使用、修改或共享創意作品，便需要版權所有者的許可。諸如音樂、電影等，都是它們的創作者的知識產權。當作者以 copyleft 許可證發布程序時，他們主張對該作品的版權（make a claim on the copyright of the work），并聲明只要保持權利對等（reciprocity of the obligation），其他人便有權使用、修改和共享該作品。簡而言之，如果他們使用具有這種類型開源許可證的組件，那么他們也必須開放其代碼以供他人使用。
寬松開源許可證（Permissive open source licenses）是一種非版權保留（non-copyleft）的開源許可證，可以保證使用、修改、重新分發的自由，同時還允許用于具有專利的派生作品之中。寬松開源許可證被親切地稱為「Anything Goes」（為所欲為），對他人如何使用開源代碼組件設置了最小的限制（place minimal restrictions）。這意味著這種許可證允許自由地使用、修改和重新分發開源代碼，允許用于專利作品中，并對此不求回報。
備忘
了解頂級開源許可證
首先要強調的是，沒有什么「好的許可證」，也沒有什么「不好的許可證」，而且也不存在「一個許可證比另一個許可證更好」的情況。任何人都可以創建適合他們自己喜好的開源許可證，這就是為何有這么多許可證存在的原因了。這可能會是如何選擇開源許可證變得復雜，特別是對于那些對法律不太熟悉、也從未得到過對開源許可證的詳盡解釋的人。為縮小決策范圍并充分理解它們，OSI 匯總了一份已批準的許可證清單，其中包括 80 多個最常用的開源許可證。
在 OSI 清單內的幾十個開源許可證之中，其中有一些占據著上風，且被一些最受歡迎的開源項目所使用。我們匯總了這份簡要清單，羅列了一些常用的開源許可證。
GNU 通用公共許可證（GPL）
GNU 通用公共許可證（The GNU's General Public License）是最受歡迎的開源許可證。理查德·斯托曼（Richard Stallman）創建了 GPL，以保護 GNU 軟件免于被申請專利，這是他對「copyleft」概念的理解和實現。
GPL 是 copyleft 許可證，這意味著任何基于 GPL 組件編寫的任何軟件都必須開源發布。其結果是任何使用 GPL 開源組件（無論其在整個代碼中占比多少）的任何軟件都必須釋出（release）其完整的源代碼，以及修改和分發整個代碼的所有權利。
關于什么構成「某作品基于另一作品」一直存在這混淆，因為這會觸發 GPL 的對等義務。自由軟件基金會（FSF）試圖通過 GPLv3 使「何時會觸發對等義務」變得更清晰?；饡踔翞榇司帉懥诵碌?GPL 許可證—— Affero 許可證——以解決被稱作「ASP loophole」的特定混亂。
此外，自由軟件基金會還試圖增加 GPLv3 許可證與其他許可證的兼容性。只要兩個程序都允許，就可以把這兩塊代碼組合成一個更大的作品。如果兩個程序的許可證都授予了此類權利，則它們是兼容的。通過使 GPLv3 變得更兼容，自由軟件基金會擴展了開發選項。
第三個區別是 GPLv3 的目的是提高全球的使用率。與 GPLv2 所使用的語言是以美國為中心的不同，GPLv3 改進了用于描述許可的語言，以確保國際法律能理解自由軟件基金會的目的。此外，GPLv3 還允許開發人員添加本地免責聲明（local disclaimers），這有助于增加其在美國以外的國家和地區使用。
Apache 許可證
Apache 許可證 是由 Apache 軟件基金會（ASF）發布的開源軟件許可證。這是一個背靠強大社區的、流行的、廣泛部署的開源許可證。Apache 許可證允許你自由使用、修改和分發任何使用了 Apache 許可證的產品，但當你這么做時必須遵守 Apache 許可證的條款。
Apache Group（后改名為 Apache 軟件基金會）在 1995 年發布了其許可證的第一個版本，但很少能遇到仍然使用該許可證的軟件組件。
在 2000 年，當伯克利（Berkeley）接受自由軟件基金會（Free Software Foundation）提出的觀點，并從 BSD 許可證中移除廣告條款形成修改的 BSD 許可證（或稱 The 3-Clause BSD License）時，Apache 也這么做了，并創建了 Apache 許可證 1.1 版本。
移除廣告條款，意味著當你使用了基于 Apache 許可證開源的軟件組件時，你的作品的推廣信息中不需要包含 Apache 許可證署名——只需要將他們包含在文檔中即可。
2004 年 ASF 決定徹底擺脫 BSD 模式，通過授予專利權（patents rights）及對「solid definitions」概念的定義，使其變得更清晰有條理，由此產生了 Apache License 2.0。
Microsoft 公共許可證（Ms-PL）
Microsoft 公共許可證（The Microsoft Public License）是微軟為釋出開源項目而編寫和發布的免費開源軟件許可證。
你可以自由地復制（再制造，reproduce）和分發（distribute）簽署了 Ms-PL 許可證的原始軟件或衍生產品。但在使用時不能使用任何貢獻者的名字（contributors' name）、Logo 或商標。Ms-PL 許可證通過「不為你所使用的代碼提供任何明確的保證（warranties）或承諾（guarantees，一般與質量有關）」來保護作者，因此如果代碼在某些情況下無法正常工作，作者也不必承擔任何責任。
當你使用 Ms-PL 許可證分發軟件（整體或部分）時，無需分發其源代碼。你也可以分發對應的源碼，但這不屬于一種義務。但是，你必須保留該軟件最初的所有版權、專利、商標和所有權聲明。
此外，如果你以源碼的形式分發軟件的任一部分，則只能在 Ms-PL 下通過在分發時包含此許可證的完整副本來執行此操作。如果以編譯或目標代碼（object code）的形式分發軟件的任一部分，則只能在符合 Ms-PL 的任何其他許可證下才能執行此操作。
需要注意的是，Ms-PL 條款和條件文檔都非常簡短清晰，且使用非常連貫的語言編寫。微軟希望與開源社區保持清晰和直接的關系，這有助于提高許可證的采用率（正如我們從 BSD 許可證中了解到的那樣）。
BSD 開源協議（伯克利軟件套件）
BSD 許可證或原始 BSD 許可證（the original BSD License）及其兩個變體——修改的 BSD 許可證（又稱 The 3-clause BSD License）和簡化的 BSD 許可證/FreeBSD 許可證（又稱 BSD 2-Clause "Simplified" License）是許可的自由軟件許可證系列。
只要你保留版權聲明、條件清單（list of conditions）和免責聲明（disclaimer）的副本，BSD 許可證就可以讓你自由地以源代碼或二進制格式修改和分發軟件代碼。
原始 BSD 許可證（或稱 The 4-Clause BSD License）還包含廣告條款（Advertising Clause）和非認可條款（Non-Endorsement Clause）（在以下問題中提供了關于這些條款的詳細說明）。修改的 BSD 許可證（或稱 The 3-Clause BSD License）是通過從原始 BSD 許可證中移除了廣告條款而形成的。此外，通過從修改的 BSD許可證中移除非認可條款后，形成了簡化 BSD許可證/FreeBSD 許可證（或稱 The 2-Clause BSD License）。
通用開源和發行許可證（CDDL）
通用開源和發行許可證（CDDL）是由太陽微系統公司（Sun Microsystems）發行的開源許可證，旨在用于替換 Sun 公共許可證 （SPL，Sun Public License）。CDDL 許可證被 Sun 公司（現在已被甲骨文公司收購）視作 SPL 的第二版本，此外 CDDL 許可證受到了 Mozilla 公共許可證（MPL，Mozilla Public License）的啟發。Sun 公司一直以來都使用 SPL 許可證發行它的自由軟件（free software）/開源項目，直到 2004 年才切換到使用 CDDL 許可證。CDDL 許可證通常被稱作 MPL 的清潔版本（cleaned up version），旨在促進可重用性（reusability）。
你可以自由地復制（再制造）和分發 CDDL 下軟件的任何原始或衍生作品，但你不得刪除或修改軟件中所包含的任何版權、專利或商標聲明。你還必須保留所有許可證聲明和屬于所有貢獻者與初始開發者的描述性信息。
當你以可執行形式（除源碼外的其他任何形式）分發軟件時，你需要將源代碼也置于 CDDL 之下?？蓤绦行问娇梢砸?CDDL 或任何與 CDDL 兼容的許可證發布。
源碼中必須包括你的貢獻（對原始軟件的既有文件和新添文件的內容的增加、修改和刪除）。這意味著，如果添加的內容在不包含原始代碼的獨立文件之中，那么就不必將之置于 CDDL 下進行發布。如果你愿意，你可以放入 CDDL 下，但這不屬于你的義務。
此外，不管你分發什么源代碼都必須包含 CDDL 的副本。對于你所做的每一個修改（modification），你都必須在所修改的文件內寫明自己是修改者，以告知他人。
Eclipse 公共許可證（EPL）
Eclipse 公共許可證（EPL，Eclipse Public License）是由 Eclipse 基金會（Eclipse Foundation）開發的開源許可證，它源自通用公共許可證（CPL，Common Public License）。現在使用 EPL 許可證的 Eclipse codebase 以前都是用 CPL 許可證。
EPL 許可證是 copyleft 許可證。如果你修改了基于 EPL 的組件并將其作為程序的一部分、并以源碼的形式分發，則需要在 EPL 許可證下公開修改后的代碼。如果你以目標代碼（object code）的形式發布，則必須聲明可根據需要將源碼提供給接收者，同時你也必須共享請求源碼的方法。
Eclipse 基金會（Eclipse Foundation）明確指出，在他們看來，與 Eclipse 插件「僅交互或互操作」是不會導致你的代碼變為該插件的衍生作品（derivative work）的。
如果你重新分發（redistribute）帶有 EPL 組件的程序，就必須包含完整的許可證文本和版權信息。
如果有企業在其商業產品中使用了 TA 的組件，那么 EPL 許可證可以保護作者免受潛在的訴訟和損失。此外，EPL 許可還提供了專利授權。
MIT 許可證
MIT 是最寬松的自由軟件許可證之一?；旧希阒恍枰砑釉?MIT 許可證和版權聲明副本（copy of the original MIT license and copyright notice），就可以自由使用基于 MIT 許可證的軟件組件了。它的簡單性使其在開發這中間得以廣泛采用。
了解你的開源許可證
或向法官解釋
如果你讀到這里，你就會明白制訂開源許可證并非出于膽小。
但是考慮到幾乎所有軟件開發者都嚴重依賴開源組件這一事實，對開源許可證有所了解，并清楚流行的許可證之間的異同是十分重要的。
我們希望這篇文章能讓你更快發現許可證內潛藏的地雷。
原題：Open Source Licenses Explained
鏈接：https://resources.whitesourcesoftware.com/recommended/open-source-licenses-explained
作者：Ayala Goldstein
