為了保護程式碼和組織,需要了解管理程式碼使用的軟體授權條款,本文針對開源授權條款及其潛在法律風險,說明對於編寫的程式庫和架構的影響性。
什麼是軟體授權條款(software license)?
企業在撰寫創新的軟體時,通常也會重複使用程式碼,包括程式碼片段、程式庫、函數、架構和整個應用程式。事實上,在大多數應用程式中,其程式碼大都包含重複使用的第三方元件。而如果被他人使用或合併到公司的程式碼庫中,這些被重複使用的軟體程式碼都具有一定的權利和義務。即使是從Stack Overflow複製的程式碼片段也有重複使用的義務。大多數第三方元件都是開源的,開源軟體是免費的,但並非沒有義務—它是由另一種授權條款所管控:軟體授權條款(software license)。
軟體以不同的方式獲得授權,不遵守授權的負面影響其實很大。根據2024 年「開源安全和風險分析」(Open Source Security and Risk Analysis;OSSRA)報告中提供的統計,在所有被掃描的程式庫中有53%包含授權條款的衝突(conflicts),顯現這是現實世界中的一個跨領域挑戰。
如果公司在未經許可或不遵守授權義務的情況下重複使用元件,版權所有者可能會提起訴訟。公司可能會面臨被禁止進一步散布被誤用的組件、賠償金,或者可能必須發布自己的原始碼。所以大多數公司都希望「乾淨(clean)」地使用第三方軟體。為了保護程式碼和組織,您需要了解管理程式碼使用的軟體授權條款,包括不是自己編寫的程式庫和架構。以下是開源授權條款及其潛在法律風險的清單。
不同類型的軟體授權條款
![圖一 : 為了保護程式碼和組織,在程式碼庫中重複使用元件常見多種授權模式類型。](/art/2024/08/221517162180/p1S.JPG)
圖一 : 為了保護程式碼和組織,在程式碼庫中重複使用元件常見多種授權模式類型。 |
|
以下是在程式碼庫中重複使用元件常見的五種授權模式類型,及容易被誤解的公共領域軟體與常見的未授權類別。
● 寬容型(Permissive):寬容型授權條款對如何修改或重新分發軟體包含最低限度的限制。它們也被稱為「歸屬式(attribution style)」授權條款,因為它們通常只要求在使用或散布軟體時、將版權資訊保留在通知文件中。此類軟體授權條款是最受歡迎的開源授權條款類型。此類別中最著名的範例是Apache授權條款、BSD授權條款和常見的MIT授權條款。
● 弱著作傳(Weak copyleft):GNU寬鬆通用公共授權 (The GNU Lesser General Public License)又稱為「Weak Copyleft」授權。它的設計目的是允許連結到開源庫而只需承擔少數的義務。
如果軟體動態連結到LGPL授權的資料庫,則整個作品可以在許可的情況下進行散布,甚至在一些專有授權(proprietary license)的使用也只有低度要求。但如果是靜態連結或修改庫就會使授權變得更加複雜。而當使用LGPL授權的元件也需要遵守其相關Copyleft義務,其他Weak Copyleft授權(包括MPL、CDDL和Eclipse)則是介於寬容型和Copyleft之間。
● 著作傳(Copyleft):Copyleft授權條款也稱為互惠(reciprocal)授權條款或限制性(restrictive)授權條款。一般來說,這類型比其他授權條款較不適合於商業運用,而其中最知名也最常用的是「通用公共授權(GPL)」系列授權。
這些授權條款允許開發人員修改授權代碼,將其與專有代碼合併,並基於上述修改分發新作品,只要他們在同一軟體授權條款下、將原始程式碼分發到任何新作品或改編作品即可。(舉例而言,Affero通用公共授權條款[AGPL]彌補了「SaaS漏洞(loophole)」,而它是在原來的軟體中即有部署,而不僅僅是在後續分發時中所觸發的。)這其中的問題是,這些授權條款需要分發原始碼以及新的衍生作品。而包含有GPL授權程式碼的作品授權需要分發專有原始碼,然而對用戶或競爭對手公開原始碼通常不符合公司的利益。因此,建立商業應用程式的公司往往會避免使用具有此類授權條款的軟體。
● 商業或專有(Commercial or proprietary):在軟體授權條款中,這類的授權條款是限制性最強的。此類授權條款通常用於商業軟體,其中版權所有者對所授予的權利提出明確的條件,例如,不希望程式碼被共享、逆向工程(reverse-engineered)、修改、重複散布或出售。
● 雙重的(Dual):版權所有者也可針對不同的使用者,採不同的的授權來提供其軟體。一種日益常見的商業模式是雙重授權,也就是同時使用Copyleft或其他形式的開放但限制性許可和商業許可。其優點是使用開源授權條款,讓開發人員輕鬆獲得程式碼並試用,但伴隨的義務是,如果公司真的想透過該軟體賺錢,就需要支付費用商業授權條款。AGPL授權通常是採用這類方式,並且出現一些更具商業限制的新變體,例如伺服器端公共授權(Server Side Public License)。
● 公共領域(Public domain):有些軟體屬於公共領域。一般來說,軟體作品受版權保護,這意味著以任何方式使用該軟體都需要獲得創作者或版權所有者的許可,即授權條款。然而,著作權不能援用於被認定是公共領域的作品,任何人都可以不受任何限制地修改和使用此類軟體。但是公共領域的程式碼通常很少見,而且對於不同司法管轄區而言,其定義也有所不同。
● 無證(Unlicensed):這類軟體沒有明確授權的程式碼,本質上也不屬於公共領域;通常在預設情況下,需要授權條款才能使用這類軟體。因此,如果公司無法將其使用的軟體與授權條款相關聯,則可能違反著作權法。
如何判斷授權條款適用類別的軟體程式庫
![圖二 : 想要確定授權條款管理程式庫中的任何元件之授權權限,需要程式碼中所有元件的清單。](/art/2024/08/221517162180/p2S.JPG)
圖二 : 想要確定授權條款管理程式庫中的任何元件之授權權限,需要程式碼中所有元件的清單。 |
|
想要確定授權條款管理程式庫中的任何元件之授權權限,就需要軟體物料清單 (software Bill of Materials;SBOM),也就是程式碼中所有元件的清單。企業可以建立政策、流程、培訓和軟體組成分析(SCA)工具等既定計劃,並隨時保持準確的 SBOM。一份好的SCA工具將能夠找到完整的組件以及程式碼,它可能協助企業哪些授權條款適用於每段程式碼,以及是否可能使用有衝突的授權條款,此外,還可以識別已知的安全漏洞。如果沒有上述工具,在併購的交易中,企業大概只能仰賴值得信賴且有能力的第三方審計單位,來及時提供準確的相關資訊。
一旦建立了SBOM,再加上SCA工具或審核員的協助,大多數授權議題將變得更容易理解。但正如本文所強調的,有時情況並非總是如此,而最佳作法是聘請一位精通開源軟體的智慧財產權律師,就可以為複雜的問題提供建議。
(本圖文由Synopsys提供;作者Phil Odence為管理諮詢顧問暨執行長)