開源許可證開發人員指南

已發表: 2022-03-11

並非所有開源許可證都是相同的。其中一些規定軟件供應商有義務向軟件的用戶和開發人員授予專利許可。其他許可要求使用許可產品或庫的開發人員在相同條款下提供該產品或庫的源代碼。其他人只是放棄代碼，沒有任何形式的保證或任何擔憂。在本文中，我將嘗試從軟件用戶和軟件開發人員的角度強調最常用的開源許可證之間的主要區別。

揭開神秘的面紗——開源許可證

鳴叫

1984 年，Richard Stallman 開始創建自由操作系統的 GNU 項目時，他恢復了軟件應該在開發人員、工程師和用戶之間共享的想法。他們應該能夠以與科學通常相同的方式以協作的方式改進它。

此選項與大多數軟件公司和開發商選擇用於分發和銷售其程序的許可軟件的通常概念形成對比。三十多年後的今天，開源軟件緩慢地繼續征服我們行業的廣泛領域：Linux、Android、Apache 和 Git 是其類別中領先的開源產品的例子。

開源還是免費軟件？

在本文中，在提及軟件或許可證時，我將使用術語“開源”和“免費”作為同義詞。在我看來，這兩個術語都表達了相同的想法。 “開源”以實用和技術的方式表達它，使用“免費”將重點放在概念的哲學和政治含義上。

不幸的是，英語中的“免費”一詞除了是與“自由”相關的形容詞外，還意味著“免費”。這就是我通常更喜歡說“開源”的原因。

開源軟件的共同屬性

我想您已經大致了解什麼是開源軟件。但是當我們要討論不同許可證的細節時，首先我們需要談談定義開源軟件的特定屬性。

首先：我不是律師，這不是法律建議。如有疑問，請參閱我所說的許可證的實際文本，並諮詢您的法律顧問。

根據 Open Source Initiative 的說法，所有開源軟件都是根據許可分發的，該許可賦予其用戶和開發人員（被許可人）一些權利。完整列表可以在開源定義中查閱，但這裡是一個基本摘要：

軟件的免費再分發：軟件可以作為產品出售或贈送或包含在軟件包中。這可以在不支付任何版稅的情況下完成。
許可軟件的源代碼要么包含在分發中，要么至少有廣為人知的獲取源代碼的方法。此源代碼可用於開發軟件的修改版本。
允許創建派生作品，並且許可允許它們在與原始軟件相同的條款和許可下分發。根據原始軟件的許可證，在某些情況下，這些衍生作品必須通過更改名稱或版本號來與原始軟件區分開來，或者只能以源代碼補丁的形式分發。
該軟件可以由任何人或群體使用，並且可以在任何努力領域中使用，沒有任何限制。

那麼，我們可以在產品或項目的開發中使用開源軟件嗎？基本上，它取決於所用軟件的許可證和最終產品的預期許可證。當您想將自己的代碼作為開源發布並且您正在決定應該使用哪個許可證時，不同的許可證也很重要。

Copyleft

關於開源許可證的一個非常有趣的概念是通常稱為 copyleft 的東西，它與版權相反。在使用版權保護知識產權（包括軟件）不被複製或分發的情況下，copyleft 用於確保開源知識產權和軟件可以作為開源進行複製或分發。

根據其實力，copyleft有兩種：

強版權左：當作品衍生自其他強版權許可作品或鏈接到這些作品時，必須繼續擁有強版權許可，甚至完全相同的許可。也就是說，那些開源的作品以後不能關閉。
弱 Copyleft：當作品使用弱 Copyleft 許可作品或與之鍊接的作品時，可以在其他許可下獲得許可，甚至是閉源許可。在這種情況下，copyleft 只影響原始的弱 copyleft 許可作品。

也有沒有 copyleft 的開源許可證：他們根本不關心派生軟件的未來開放性。

放任

根據許可程度，許可證還可以分為：

嚴格的許可：當您不能將強大的許可軟件與封閉源代碼甚至更寬鬆的許可軟件混合使用時。
許可許可：產品通常可以與閉源軟件或具有完全開源許可的軟件混合使用。

通常，強 copyleft 許可證也很嚴格，而弱 copyleft 許可證則更寬鬆，但不一定要那樣。

開源許可證差異

存在許多開源許可證。開源計劃已經批准了其中的 80 多個。有些是多餘的，可以被認為與其他的等效。其他則特定於軟件發布者的利益（例如 NASA 許可證），或特定環境或目的（例如教育社區許可證或開放字體許可證）。

許可證的這種擴散是基於許可證中的特定條款，這些條款添加到基本的開源屬性中，允許或禁止其他用途。這些附加條件的示例包括：

Copyleft 的類型：弱或強或不存在。
許可類型：許可或嚴格。
在源代碼或用戶界面中添加版權聲明的義務。
自動授予被許可人專利。
不僅將軟件分發方和軟件用戶視為被許可人（因此使用此類開源軟件的雲服務的人應該可以選擇下載源代碼）軟件）

混合代碼與不同許可證的問題

根據我們之前已經說過的，一些許可是許可的，允許用戶將代碼與不同許可的源代碼組合（可能帶有附加條件）。這種情況將允許將這種開源許可軟件與閉源軟件混合使用。這種許可證的一個例子是 MIT 許可證。

其他的限制性更強，所以源代碼只能與以類似方式獲得許可的代碼組合，並且最終結果必須使用相同的原始許可進行許可。此類許可證的一個示例是通用公共許可證 (GPL)。

也許您想將許可的代碼與兩個不同的限制性開源許可結合起來。使用開源自由來隨心所欲地使用軟件，您可以做到這一點。但是最終的程序不能重新分發，因為它應該在兩個互不兼容的許可證下分發。

這種情況的一個例子是 ZFS。 ZFS 是一個非常先進和創新的文件系統，於 2005 年包含在 OpenSolaris 中。它是根據通用開發和分發許可 (CDDL) 條款獲得許可的開源軟件。雖然它是開源代碼，但它不能集成到 Linux 內核中，因為 Linux 的源代碼是根據通用公共許可證的條款分發的，這是另一個限制性的開源許可證。由於許可證衝突，無法分發使用 ZFS 支持編譯的 Linux 內核的二進製文件。

只有當其中一個開源程序的所有所有者都同意更改許可或在軟件許可中添加例外條款時，才能解決此類衝突。例如：很多 GPL 許可程序都與 OpenSSL 庫鏈接。 OpenSSL 庫分發已獲得許可，要求在廣告材料和任何重新分發中出現短語。這些額外的條件與 GPL 不兼容，因此使用 OpenSSL 的 GPL 產品的開發人員在他們的許可證中包含了一個例外，特別是允許與 OpenSSL 鏈接。

開源許可證的不同特徵

現在我將嘗試分析最流行的開源許可證，說明它們的不同特性，並提供一些關於何時使用它們的指南。根據 Black Duck 知識庫，我已將它們從使用多到少排序。

GNU 通用公共許可證 (GPL)

GPL 是最流行的開源許可證。它是由 FSF 創建的，作為 GNU 項目的許可證，也是 Linux 內核的許可證。

其差異化特點：

強版權。
非常嚴格的執照。
它通常被稱為“病毒”許可：如果您將您的代碼鏈接到另一段根據 GPL 許可的代碼並希望分發結果，則整個產品必須是 GPL 許可的。
它也是一個“包容性”許可：如果您正在開發軟件並希望根據 GPL 許可它，您可以鏈接它或包含其他開源軟件，只要該軟件具有與 GPL 兼容的許可。它不需要 GPL 不要求的任何義務。

通常，使用的許可文本包括說明該軟件是根據 GPL 版本 N（或任何更高版本）的條款分發的文本。

目前使用的 GPL 許可證有兩個版本：v2 和 v3。第 3 版於 2007 年發布，用於解決自 1991 年第 2 版發布以來出現的一些問題。

GPL v3 包括一些額外的條款和條款，涉及與其他開源許可的兼容性規定，強制專利許可，定義使用 GPL 許可軟件作為設備固件的條件，並考慮到數字版權管理的概念。

麻省理工學院許可證

開源許可證通常稱為 MIT 許可證，又名 X11 許可證，是一種非常寬鬆的非 Copyleft 許可證，只要您保留版權信息並知道該軟件不提供任何形式的保證。

該許可證非常流行，並被多個項目使用，例如 X Window System、Ruby on Rails、jQuery 或 Node.js。

它與 GPL 兼容，因此您可以將 MIT 許可的代碼混合到 GPL 軟件中。

阿帕奇許可證 2.0

Apache 許可證由 Apache 軟件基金會 (ASF) 創建，作為其 Apache HTTP 服務器的許可證。

就像 MIT 許可證一樣，它是一個非常寬鬆的非 copyleft 許可證，允許將軟件用於任何目的、分發、修改和分發其衍生作品，而無需擔心版稅。與 MIT 許可證相比，它的主要區別是：

使用 Apache 許可證，軟件的作者將專利許可授予代碼的任何用戶或分發者。本專利許可適用於任何由軟件作者許可的、會被他們創建的代碼侵犯的專利。
Apache 許可證要求衍生作品中未修改的部分保留許可證。
在每個許可文件中，必須保留任何原始版權、專利、商標或歸屬聲明。
在每次許可文件更改中，必須有通知說明文件已進行更改。
如果 Apache 許可軟件包含 NOTICE 文件，則該文件及其內容必須保留在所有派生作品中。
如果有人故意向其作者發送 Apache 許可軟件的貢獻，則此貢獻可以自動在 Apache 許可下使用。

這個許可很有趣，因為它有自動專利許可，以及關於貢獻提交的條款。

它與 GPL 兼容，因此您可以將 Apache 許可代碼混合到 GPL 軟件中。

BSD 許可證

有 3 種不同的 BSD 許可證。所有這些都是非常寬鬆的許可證，沒有 copyleft。

2 條款 BSD 許可證（或簡化的 BSD 許可證）完全等同於之前解釋的 MIT 許可證。

GNU 小通用公共許可證 (LGPL)

LGPL 由 FSF 創建，作為 GPL 的修改，具有較弱的左版，允許將 LGPL 許可的軟件與任何其他軟件鏈接。 LGPL 最初代表“圖書館通用公共許可證”，但後來改名為“次通用公共許可證”，代表 FSF 的意見，即所有軟件都應該是免費的，因此 LGPL 不應該是免費的。一般使用。

您可以將封閉源代碼鏈接到 LGPL 庫或軟件並分發最終結果，只要：

您提供 LGPLed 部分的源代碼，以及您對其所做的所有修改。
任何有足夠知識的用戶都可以用修改後的版本替換程序的 LGPL 部分。這可以通過將程序的 LGPL 部分作為動態庫（Windows 中的 DLL，Linux/Unix 中的 .so）分發，或提供程序的非 LGPL 部分的目標代碼來完成。

LGPL v3 與 GPLv3 兼容，因此您可以將 LGPLv3 代碼輸入 GPL 軟件。

藝術許可證

藝術許可證，在其當前版本 2.0 中，是一個與 MIT 許可證類似的無版權許可的開源許可證。

MIT 許可證和藝術許可證之間的主要區別在於後者要求對代碼所做的任何修改都必須明確說明。

該許可證幾乎專門用於 Perl 社區。

當前的 Artistic License 2.0 與 GPL 兼容：您可以將 Artistic-Licensed 代碼混合到 GPL 軟件中。

微軟公共許可證 (MS-PL)

Microsoft 公共許可證由該公司於 2008 年創建，作為其共享源計劃創建的開源許可證之一。

這是一個嚴格的、弱的 Copyleft 許可證：它允許使用 MS-PL 代碼創建和分發閉源程序，但如果這些以源代碼分發，它必須使用 MS-PL 作為派生作品的許可證。

MS-PL 與 GPL 不兼容。

Eclipse 公共許可證 (EPL)

Eclipse 公共許可證是 Eclipse 基金會為其集成開發環境創建的許可證。這是一個限制性和弱版權許可，在許多方麵類似於 LGPL。它還包括自動授予專利許可的條款。

EPL 與 GPL 不兼容。

Mozilla 公共許可證 (MPL)

Mozilla 公共許可證 2.0 版是由 Mozilla 基金會為其產品創建的弱版權左許可許可證。

我們可以將此許可證視為類似於 LGPL，但主要區別在於 MPL 還允許將 MPL 代碼段靜態鏈接到閉源軟件中。

MPL 在其當前版本 2.0 中與 GPL 兼容。這不適用於以前版本的 MPL。

通用開發和分發許可證 (CDDL)

CDDL 是由 Sun（現為 Oracle）基於 MPL 1.1 版創建的弱版權左許可許可。基本上，它具有與 MPL 相同的屬性。其條款得到澄清，但沒有實質性改變。

CDDL 是 Sun（現為 Oracle）為其許多產品（如 OpenSolaris 或 NetBeans 等）選擇的開源許可證。

由於此許可證基於 MPLv1.1，因此此許可證與 GPL 不兼容，因此您不能將 CDDL 許可的源代碼混入 GPL 許可的軟件中。很多人說這是故意的，所以不能將 OpenSolaris 源代碼引入 Linux 內核。

GNU Affero 通用公共許可證 (AGPL)

AGPL 是 GPL 的一個版本，具有更強大和更嚴格的 copyleft。它有義務將應用程序的源代碼不僅提供給接收軟件副本的人，而且還提供給通過計算機網絡使用該軟件的人。

該許可證由 FSF 創建，旨在為開發人員提供避免在網絡服務器或云中執行開源軟件時實際關閉的方法，因為 GPL 不能強制服務提供商向用戶提供源代碼. 在這種情況下，軟件不會分發。

AGPLv3 與 GPL3 兼容。您可以將 AGPLv3 代碼放入 GPLv3 代碼中，只要最終結果在 AGPLv3 下獲得許可即可。

ISC 執照

ISC 許可證是由 Internet 軟件聯盟 (ISC) 編寫的許可自由軟件許可證。在刪除了一些被認為不必要的語言之後，它在功能上等同於 2 條款 BSD 和 MIT 許可證。

最初用於 ISC 自己的軟件版本，它已成為 OpenBSD 的首選許可證（從 2003 年 6 月開始），以及其他項目。

它與 GPL 兼容：您可以將 ISC 許可代碼混合到 GPL 軟件中。

微軟互惠許可證 (MS-RL)

Microsoft Reciprocal License 由該公司於 2008 年創建，作為其共享源計劃創建的開源許可證之一。

它類似於前面解釋的 MS-PL，但它有更強的 copyleft，類似於 LGPL、CDDL 和 EPL 的條件。它要求，如果您將代碼與 MS-RL 許可的源代碼混合併希望分發最終結果，則至少原始 MS-RL 許可的部分必須繼續獲得此許可的許可。

它與 GPL 不兼容。

公共領域 (CC0)

根據維基百科，“公有領域的作品是指知識產權已過期、被沒收或不適用的作品”。將作品奉獻給公共領域，作者放棄了他根據版權法對其擁有的所有權利。

Public Domain 下有幾個軟件項目，例如 SQLite，該庫實現了一個可嵌入的簡單 SQL 數據庫引擎，它包含在其他幾個項目中，例如 Mozilla 項目、Android 等。

有很多方法可以將軟件專用於公共領域。知識共享創建了 CC0 公共領域奉獻，這是一種將作品送入公共領域的通用方式。 FSF 建議使用此文本將軟件專用於公共領域。

公共領域下的作品與任何開源或閉源許可證兼容，並且可以混合到任何其他軟件中。

多重許可

有一些開源軟件是雙重甚至三重許可的。這意味著接收此多重許可軟件的人可以選擇他或她想要分發它的許可。由於每個許可證授予不同的權限並施加不同的義務，因此必須選擇最能滿足需求的許可證。

這是某些庫的常見情況。例如，NSS 是 Mozilla 開發的一個庫，它實現了 SSL/TLS 支持以及其他與安全相關的功能。它在 MPL、GPL 和 LGPL 許可下獲得三重許可。

請選擇許可證

很多人在沒有任何書面許可的情況下在 GitHub 平台上發布代碼。沒有人應該使用該代碼。我們不知道我們有什麼使用它的權限。如果你使用它，你可能會因此被起訴。就好像這些人在取笑我們，說：“嘿，看看我做了什麼！酷，不是嗎？但你不能用，我只是想給你看！”。

請不要成為其中之一。如果您將代碼上傳到 GitHub 或類似的公共站點，請允許其他人使用並增強它。如果你不想想太多，以下是我的建議：

如果你想保持簡單和寬容，允許每個人對你的代碼做他們想做的事，只要他們向你提供歸屬並且不追究你的責任，請使用 MIT 許可證。
如果您想保持許可，允許每個人對您的代碼做他們想做的事，但明智地列舉版權法下的權利並授予這些權利，同時提供貢獻者向用戶明確授予專利權，請使用 Apache 2.0 許可證.
如果您關心共享修改並且不希望您的代碼用於封閉式開發（既不封閉式軟件產品也不封閉式硬件設備），請使用 GPL v3。
- 如果您不關心您的軟件在封閉設備中使用的可能性，請使用 GPL v2。但是請加上“或任何更高版本”的句子，這樣你的代碼也可以在 GPLv3 項目中使用。
- 如果您不關心您的軟件在封閉軟件中被使用的可能性，只要您的軟件或使用它的部分在相同條款下繼續開源，請使用 LGPL v3。
- 如果您希望通過網絡使用您的軟件的每個人都有權獲取其源代碼，請使用 AGPL v3。

畢竟，您可能已經厭倦了所有這些幾乎是胡說八道的準法律胡言亂語。但是你知道嗎？這是需要的。因為沒有許可證，您就沒有使用或分發任何代碼的權利。