探索常見的開放原始碼授權

存在數百個開源許可證，但大多數開源軟體使用相對較少的流行許可證。 了解這些常見許可證、其條款及其影響有助於組織就哪些開源元件可以安全地合併到其軟體中做出明智的決策。

授權範圍

開放原始碼授權的光譜從高度寬鬆到強式 copyleft：

寬鬆（附加歸屬的）授權

在光譜的左側為寬鬆的授權，其施加的限制最小：

• 特徵： 允許在專有軟體中使用程式碼，而不需要開源專有軟體。
• 主要要求： 歸屬 — 保留版權聲明和授權文字。
• 商業用途： 與構建和銷售專有商業軟件完全兼容。
• 下游自由度： 使用者可以選擇是否開源衍生作品。

範例： MIT 許可證、Apache 許可證 2.0、BSD 許可證。

Copyleft 授權

光譜的右側是具有強式互惠要求的 Copyleft 授權：

• 特徵： 要求衍生作品和組合作品使用相同的許可證。
• 病毒性質： 授權會「傳播」至包含授權程式碼或與授權程式碼結合的軟體。
• 原始碼要求： 二進位檔的分發需要提供原始程式碼。
• 維護自由： 確保軟體在發展過程中保持開源並納入其他專案。

範例： GNU 通用公共許可證（GPL v2 和 v3）、GNU Affero 通用公共許可證 （AGPL）。

弱 Copyleft 許可證

位於光譜中間的是弱式 copyleft 授權，它們在開放性與商業可行性之間取得了平衡：

• 特徵： 要求對授權元件進行修改以開源，但允許將該元件合併到更大的專有作品中。
• 圖書館友善： 專為可用於專有應用程式的函式庫而設計。
• 檔案層級或模組層級 copyleft： 需求適用於授權元件本身，而不是整個應用程式。
• 實用平衡： 實現商業用途，同時確保組件的改進保持開放原始碼。

範例： GNU 寬鬆通用公共許可證 （LGPL）、Mozilla 公共許可證 （MPL）、Eclipse 公共許可證 （EPL）。

常見的寬鬆授權

麻省理工學院許可證

MIT 許可證是最簡單、最寬鬆的開源許可證之一：

關鍵術語：

• 權限： 使用、複製、修改、合併、發布、分發、再授權和銷售軟體。
• 條件： 在所有副本或實質部分中包含版權聲明和授權文本。
• 限制： 不提供保證，不承擔損害賠償責任。

為什麼項目選擇麻省理工學院：

• 最大採用率： 最少的限制鼓勵廣泛使用。
• 簡單明了： 易於理解的簡短授權文字。
• 商業友好：將MIT許可的代碼合併到專有軟體中毫無阻礙。
• 靈活性： 用戶在如何使用和分發軟件方面擁有完全的自由。

麻省理工學院授權熱門項目： React、Angular、Node.js、jQuery、Rails、.NET Core。

對組織的影響：

• 商業用途安全：可以不受限制地將 MIT 授權的元件整合到專有軟體中。
• 需要註明出處： 必須保留著作權聲明 - 通常透過在應用程式文件或「關於」對話方塊中包含授權文字來滿足。
• 無專利授權： 麻省理工學院許可證沒有明確解決專利問題，造成了潛在的歧義。

Apache 授權 2.0

Apache 許可證 2.0 是一種具有明確專利保護的寬鬆許可證：

關鍵術語：

• 權限： 使用、複製、準備衍生作品、展示、表演、再授權和分發。
• 條件： 包括版權聲明、許可文本和修改通知；保存專利聲明；提供歸屬。
• 專利授權： 貢獻者明確授予專利權。
• 專利報復： 如果被許可人對貢獻者提起專利訴訟，專利授權就會終止。
• 限制： 不保證，不承擔任何責任，不承擔商標權。

為什麼專案選擇Apache 2.0：

• 專利明確性： 明確的專利授予提供了法律確定性。
• 修改透明度： 要求記錄修改可提高透明度。
• 企業信心： 明確的條款和專利保護使企業能夠放心地做出貢獻。
• 相容性： 與 GPL v3 相容（但不相容於 GPL v2）。

熱門的Apache 2.0專案： Kubernetes、TensorFlow、Android、Spring Framework、Apache Hadoop、Apache Kafka。

對組織的影響：

• 專利保護： 明確的專利授予可降低貢獻者提起專利訴訟的風險。
• 修改通知： 必須指出檔案何時被修改。
• 歸屬要求： 比麻省理工學院稍微複雜一些，需要保存 NOTICE 文件。
• 防禦終止： 如果您起訴貢獻者侵犯專利權，專利授權將終止，鼓勵和平共處。

BSD 授權條款（2條款及3條款）

BSD（伯克利軟體發行）許可證是類似於 MIT 的寬鬆許可證：

BSD 2 子句（簡化 BSD）：

• 權限： 以原始碼和二進位形式重新分發和使用，無論是否進行修改。
• 條件： 保留版權聲明、條件列表及免責聲明；在二進位發行版的文件中保留來源歸屬。
• 限制： 不保證，不承擔任何責任。

BSD 3 條款（修改後的 BSD）：

• 附加條件： 未經許可，不得使用版權所有者的姓名來代言衍生產品。
• 商標保護： 防止暗示原作者的認可。

熱門BSD授權專案： FreeBSD、OpenBSD、部分 macOS 和 iOS。

對組織的影響：

• 與麻省理工學院相似： 限制最少，商業友好。
• 名稱使用限制： 3-Clause BSD 禁止未經許可使用專案名稱進行行銷。
• 成熟：在學術和商業軟件方面擁有悠久的歷史。

通用 Copyleft 授權

GNU 通用公共許可證 （GPL） v2 和 v3

GNU General Public License 是最著名的 Copyleft 授權合約之一：

GPL v2 關鍵術語：

• 權限： 使用、修改和分發軟體。
• 條件： 使用二進位檔分發原始碼。衍生作品必須使用GPL v2。保留版權聲明。
• Copyleft 範圍： 適用於與 GPL 代碼鏈接的衍生作品和組合作品。
• 限制： 不保證，不承擔任何責任。

GPL v3 增強功能：

• 專利保護： 類似於 Apache 2.0 的明確專利授權。
• 預防 Tivoization：防止使用硬體限制以阻止使用者執行經過修改的軟體。
• 國際相容性： 提高國際司法管轄區的法律清晰度。
• Apache 2.0相容性： 可以將 GPL v3 代碼與 Apache 2.0 代碼結合。

為什麼專案選擇GPL：

• 確保自由： GPL 確保修改保持開源，防止專有分叉。
• 社區建設： 鼓勵將改進分享回社區。
• 哲學一致性： 符合軟體應該保持自由的自由軟體理念。

熱門的GPL授權專案： Linux 核心 （GPL v2）、Git （GPL v2）、WordPress （GPL v2）、GCC （GPL v3）、Bash （GPL v3）。

對組織的影響：

• 衍生工作要求： 如果您修改 GPL 代碼或創建衍生作品，則在分發時必須在 GPL 下開源它們。
• 連結問題： 將專有程式碼與 GPL 函式庫連結可能會觸發 Copyleft 要求（解釋各不相同）。
• 商業發行： 可以銷售 GPL 軟件，但必須向客戶提供源代碼。
• SaaS 考量事項： 除非使用 AGPL，否則 GPL v2 和 v3 不需要軟體即服務的原始碼揭露。

GNU Affero 通用公共許可證 （AGPL）

AGPL 透過網路使用條款擴展了 GPL v3：

其他 AGPL 要求：

• 網路 copyleft： 如果您修改 AGPL 軟體，且使用者透過網路 （SaaS） 與其互動，則必須向這些使用者提供原始程式碼。
• 堵住 ASP 漏洞： 防止公司修改軟體並將其作為服務提供，而無需共享修改。

為什麼項目選擇 AGPL：

• SaaS 保護： 確保雲端服務無法在不回饋的情況下使用開放原始碼軟體。
• 更強的 copyleft：最大程度的保護，防止專屬使用。

熱門 AGPL 授權項目： MongoDB（從 AGPL 更改）、RocketChat、Grafana。

對組織的影響：

• SaaS 避免：大多數組織避免使用 AGPL 授權軟體來提供服務，因為它需要開放原始碼修改。
• 內部使用： 如果未透過網路公開給使用者，則可以在內部使用而不會觸發需求。
• 風險評估： 仔細評估軟體是否符合「透過網路互動」的條件。

常見的弱式 Copyleft 授權

GNU 寬鬆通用公共許可證 （LGPL）

LGPL 允許連結到函式庫，而不會觸發完整的 GPL 要求：

關鍵術語：

• 圖書館使用： 可以從專有軟件鏈接到 LGPL 庫，而無需開源專有應用程序。
• 函式庫修改： 對 LGPL 函式庫本身的修改必須是開源的。
• 動態連結： LGPL 明確允許使用專有程式碼進行動態連結。
• 衍生作品： 完整的應用程序不會僅僅因為它們使用 LGPL 的庫而成為衍生作品。

為什麼項目選擇 LGPL：

• 圖書館採用： 鼓勵在專有軟體中使用，同時保護程式庫本身。
• 折衷立場： 平衡開放性與商業可行性。
• 標準庫適用性： 適用於作為標準元件的程式庫。

熱門LGPL授權項目： Qt（雙重許可和商業選項）、GTK、GStreamer、許多 C 庫。

對組織的影響：

• 可用於專有應用程序： 在商業應用中安全地使用 LGPL 庫。
• 必須提供庫來源： 如果您修改 LGPL 的程式庫，請提供修改的原始程式碼。
• 靜態連結複雜度： 靜態連結可能會觸發更嚴格的要求;動態連結更安全。

Mozilla 公共許可證 （MPL） 2.0

MPL 2.0 提供檔案層級 Copyleft：

關鍵術語：

• 檔案級 copyleft：這些要求僅適用於最初在 MPL 下的文件。
• 較大的工作豁免： 可以將 MPL 文件與同一應用程序中的專有文件結合。
• 原始碼公開： 必須提供 MPL 檔案的原始程式碼。
• 專利授權： 包括明確的專利授予和防禦性終止。
• GPL相容性： MPL 2.0 與 GPL 相容。

為什麼項目選擇 MPL 2.0：

• 平衡：比寬鬆授權條款更強，比 GPL 更靈活。
• 商業用途： 實現商業用途，同時保護開源組件。
• 檔案追蹤： 檔案等級 Copyleft 使合規性更容易追蹤。

熱門 MPL 授權項目： Firefox、Thunderbird、LibreOffice。

對組織的影響：

• 可以與專有代碼混合： 與 GPL 相比，與專有軟體更容易整合。
• 檔案級追蹤： 必須在 MPL 檔案和專有檔案之間保持清晰的界限。
• 共享的修改： 對 MPL 檔案的變更必須共用，但個別檔案中的新增內容則不需要。

授權相容性

不同的授權有不同的相容性規則：

相容組合

• 麻省理工學院 + Apache 2.0： 相容 - 可以組合在同一個專案中。
• 麻省理工學院 + GPL v3： 相容 — 可以將 MIT 授權的程式碼合併到 GPL v3 專案中。
• Apache 2.0 + GPL v3： 相容 — GPL v3 可以合併 Apache 2.0 程式碼。
• LGPL + GPL： 相容 — 可以將 LGPL 升級到 GPL。

不相容的組合

• GPL v2 + Apache 2.0： 不相容 — 無法在同一工作中合併。
• GPL + 專有： 不相容 — GPL 要求衍生作品必須經過 GPL 處理。
• 不同的 Copyleft 許可證： 通常不相容 — 通常不能將 GPL、AGPL 和 LGPL 程式碼與不同的 Copyleft 授權以同時滿足兩者的方式結合。

相容性考量

選取相依性時：

• 授權清單： 瞭解所有相依性的授權。
• 相容性檢查： 驗證不同元件的授權是否相容。
• 法律審查： 複雜的案件需要法律專業知識來評估相容性。

雙重授權策略

有些專案提供多種授權選項：

開源+商業

• 策略： 根據 GPL（copyleft）或商業許可提供。
• 理由： 想要納入專有軟件的公司購買商業許可證;開源社群使用 GPL 版本。
• 範例： Qt、MySQL、MongoDB（改變了方法）。

多個開源許可證

• 策略： 允許使用者從多個相容的授權中進行選擇。
• 理由： 最大限度地提高與不同項目的兼容性。
• 範例： 某些程式庫提供 Apache 2.0 或 MIT 授權選項。

了解常見的開源許可證、其條款及其相容性有助於組織就使用哪些開源元件以及如何構建其軟體以保持許可證合規性做出明智的決策。 下一個單元探討授權影響和評等，以協助評估風險並做出決策。