開放原始碼授權簡介
開源許可證 是定義如何使用開源軟體的法律協議。 每個開源項目都包含一個許可證，其中指定授予用戶的權利以及他們必須履行的任何義務。 了解許可證對於在組織環境中合法、安全地實施開源軟體至關重要。
開放原始碼授權的定義
開源許可證是源代碼隨附的法律文件，並指定：
授予的權限
授權明確授予使用者某些權限：
- 使用權利： 允許將軟體用於任何目的，包括商業應用程式。
- 修改權： 修改原始程式碼以滿足特定需求、修復錯誤或新增功能的權限。
- 分配權： 允許以原始或修改形式與他人共享軟件。
- 再授權權利： 在某些情況下，允許根據不同的條款將軟體授權給他人。
如果沒有明確許可，版權法禁止使用、修改或分發軟體。 該許可證為這些活動提供了法律許可。
施加的義務
授權通常會對使用者施加要求：
- 歸屬要求： 必須在分發副本中保留版權聲明和許可文本。
- 原始碼公開： 某些許可證需要在分發二進位文件時提供源代碼。
- 許可證保存： 必須包含授權文字和分發副本。
- 衍生作品授權： 某些許可證要求衍生作品才能使用相同的許可證（copyleft）。
- 專利授權： 一些許可包括明確的專利授予或防禦性終止條款。
責任和保證免責聲明
幾乎所有開源許可證都不承擔責任和保證：
- 無保證： 軟體按「原樣」提供，不保證適銷性、適用性或不侵權。
- 不承擔任何責任： 作者和版權所有者對因使用軟件而造成的損害不承擔任何責任。
- 用戶風險： 用戶接受與使用該軟件相關的所有風險。
這些免責聲明保護開源開發人員免於承擔法律責任，並認識到軟體通常是免費提供的，無需補償。
開放原始碼定義
開放原始碼倡議 （OSI） 維護權威的開放原始碼定義，其中規定了被視為真正開放原始碼的授權標準：
核心需求
根據 開源定義，開源許可證必須：
免費重新分發：
- 無限制： 授權不能限制任何人將軟體作為聚合發行版的一部分出售或贈送。
- 無版稅： 許可證不能要求此類銷售的特許權使用費或費用。
原始碼包含詞/句：
- 庫存情況： 分散式程式必須包含原始程式碼或提供免費取得原始碼的明確說明。
- 首選形式： 原始程式碼必須採用修改時偏好的形式。
- 無混淆： 故意混淆的原始碼不符合要求。
衍生作品：
- 允許的修改： 許可證必須允許修改和衍生作品。
- 相同條款： 授權必須允許根據與原始軟體相同的條款分發修改。
作者原始碼的完整性：
- 修補程式檔案： 授權可能需要將修改作為修補程式檔案與原始來源一起分發。
- 命名： 許可證可能要求衍生作品使用與原始作品不同的名稱或版本號。
不歧視個人或團體：
- 通用訪問： 許可證不能歧視任何人或一群人。
- 平等權利： 每個人都必須擁有相同的權利才能使用該軟件。
不歧視努力領域：
- 任何目的： 許可證不能限制軟體用於商業或基因研究等特定領域。
- 商業用途： 授權不能禁止在商業應用程式中使用軟體。
許可證的分配：
- 自動申請： 該計劃附加的權利必須適用於該計劃被重新分發的每個人。
- 沒有額外的許可證： 使用者不需要執行其他授權即可獲得這些權限。
授權不得特定於產品：
- 獨立權利： 權利不得取決於程式是特定軟體發行版的一部分。
- 獨立執行： 如果從原始發行版中提取，則該軟體必須具有相同的權利。
授權不得限制其他軟體：
- 無污染： 授權不能對與授權軟體一起分發的其他軟體施加限制。
- 允許的彙總： 授權無法防止將軟體與不同授權下的軟體一起分發。
授權必須是技術中立的：
- 無介面限制： 授權不能要求特定技術或介面樣式。
- 不限定的執行方法： 許可證不應在意軟體是透過點擊圖示、命令列還是網頁介面來執行。
為什麼這些要求很重要
開放原始碼定義確保授權提供有意義的自由：
保護使用者自由： 要求防止許可證施加會破壞開源原則的隱藏限制。
實現商業用途： 透過禁止對事業領域的歧視，該定義確保企業可以使用開源軟體建立產品。
促進相容性： 限制授權如何影響其他軟體的需求可減少相容性問題。
防止碎片化： 透過要求合理的條款，該定義可以防止不相容的準開放授權的激增。
開源許可證的類別
雖然存在許多不同的開源許可證，但它們通常分為兩大類：
寬鬆授權
寬鬆許可證對 衍生作品提出了最低要求：
- 特徵： 允許將程式碼合併到專有軟體中，而無需開源專有軟體。
- 要求： 通常只需要註明出處（保留版權聲明和授權文字）。
- 商業用途： 完全相容於商業軟體開發。
- 範例： MIT 許可證、Apache 許可證 2.0、BSD 許可證。
寬鬆的許可證最大限度地提高了使用者的自由度，允許他們創建包含開源程式碼的閉源商業產品。
Copyleft 授權
共用授權許可證要求衍生作品使用相同的許可證：
- 特徵： 確保修改版本和衍生作品保持開源。
- 要求： 要求分發原始碼並對衍生作品使用相同的許可證。
- 商業用途： 可以在商業軟體中使用，但衍生作品必須開源。
- 範例： GNU 通用公共許可證 （GPL）、GNU 寬鬆通用公共許可證 （LGPL）、Mozilla 公共許可證 （MPL）。
Copyleft 許可證將軟體自由置於使用者自由之上，確保開源軟體即使在不斷發展的過程中仍保持開源。
弱式 copyleft
有些許可證佔據中間立場：
- 允許使用程式庫： 允許在專有應用程式中連結程式庫，而無需公開應用程式的原始碼。
- 修改限制： 對函式庫本身的修改必須是開源的。
- 範例： GNU LGPL，Mozilla 公共許可證。
弱式 Copyleft 授權在促進開放原始碼開發和實現商業用途之間取得了平衡。
按專案選取授權
開源專案根據其目標選擇授權：
最大化採用率： 優先考慮廣泛採用的項目通常會選擇不會對使用者施加重大義務的寬鬆許可證。
確保自由： 優先考慮軟體自由的專案會選擇 Copyleft 許可證，以確保衍生作品保持開源。
防止專屬分叉： Copyleft 授權可防止公司建立開放原始碼軟體的專屬版本。
專利保護： 關注專利的專案會選擇具有明確專利授予的授權（如 Apache 2.0），這些授權提供更明確的專利權。
相容性： 專案可能會選擇與他們所依賴或想要整合的其他軟體相容的授權。
多個授權
某些專案使用多種授權策略：
雙重許可： 提供開源和商業許可下的軟件，讓用戶選擇適用的條款。
許可證堆疊： 專案的不同元件可能有不同的授權。
授權演進： 專案有時會隨著時間而變更授權，但這需要所有貢獻者的同意。
透明度悖論
原始程式碼透明度會帶來安全優勢和風險：
透明度的安全優勢
公開原始碼可改善安全性：
- 多隻眼睛： 成千上萬的開發人員可以審查程式碼是否有漏洞，從而增加發現的可能性。
- 更快的披露： 當發現漏洞時，可以公開披露和修補，通知所有用戶。
- 社區補丁： 具有安全意識的開發人員貢獻補丁來修復漏洞。
- 審計能力： 組織可以審核開源依賴項是否存在安全問題，這是閉源軟體不可能做到的。
透明度的安全風險
公開原始碼也協助攻擊者：
- 漏洞發現： 惡意行為者可以分析原始程式碼以發現可利用的漏洞。
- 漏洞開發： 了解實作詳細資料有助於攻擊者開發漏洞。
- 目標識別： 攻擊者可以識別哪些應用程式使用易受攻擊的開源元件版本。
- 零日漏洞利用： 攻擊者可能會在漏洞公開揭露之前發現並利用漏洞。
平衡
研究表明透明度提供了淨安全優勢：
林式定律：「若有足夠的眼球，所有的錯誤都是表面的。」開放式檢閱通常會比封閉原始碼開發更快尋找弱點並修正。
晦澀難懂不是安全： 對原始程式碼保密並不能防止漏洞，它只會隱藏它們，直到攻擊者最終發現它們。
負責任的披露： 開源社群已經制定了負責任的揭露實踐，平衡了安全性與透明度。
實際情況： 大多數嚴重的安全漏洞都涉及閉源軟體或配置錯誤，而不是開源漏洞，這表明透明度本質上不會降低安全性。
了解開源許可證及其類別為評估特定許可證奠定了基礎。 下一個單元將詳細探討常見的開放原始碼授權，協助您瞭解熱門授權所施加的術語，以及它們有何不同。