合規與風險
如何處理開放原始碼的授權風險?
漏洞並非是使用開放原始碼唯一會遇到的風險。本文中會介紹該如何減少授權相關風險，確保你的團隊在使用開放原始碼開發軟體時能夠符合法律需求。
隨著數位轉型的加速發展，開放原始碼的使用也在爆炸式的成長，這自然是因為它們能夠為開發團隊帶來的速度、靈活性、擴充性和品質。但這也擴大了受攻擊面以及新的風險，如增加法律和智慧財產權相關風險。
開放原始碼一直都受到智慧財產權保護，特別是著作權法。一旦開發人員在製作程式時使用了開放原始碼，他們的組織就有義務滿足相關授權內的條款或條件。這也是為什麼許多轉移到雲端環境一段時間的組織都有開放原始碼法律方面的資源或專職員工。
那為什麼其他企業沒有密切關注其開發團隊對開放原始碼的使用和風險處理呢？讓我們看看一些使用情境。
我確信我的開發團隊沒有大量使用開放原始碼，那開放原始碼授權有什麼關係？
簡單地說，當組織推出一款包含開放原始碼的應用程式卻沒有滿足授權要求時就侵犯了智慧財產權，需要承擔法律責任。根據Snyk的說法，如今的應用程式都至少含有80%的開放原始碼。組織需要更加了解開放原始碼的使用。不僅版權所有者可以起訴侵權行為，還有些非營利組織，如軟體自由保護協會（Software Freedom Conservancy）會監視開放原始碼的使用，並在發生侵權行為時提起訴訟。這些訴訟不僅會導致金錢上的損失，還會造成客戶和公關方面的噩夢！
開放原始碼授權只需備註確認，對嗎？
重要的是必須知道你所處理的是什麼類型的授權，才能做出最好的應對。有兩種主要的開放原始碼授權。寬鬆授權（Permissive License）遵循基本的版權概念，主要只要求權利歸屬原開發者而不要求別的。而Copyleft授權（為了與Copyright區分開來）則回歸傳統的自由軟體概念，授權條款的設計是為了促進程式碼分享。
因為簡單和易用，所以寬鬆授權（Permissive License）對商業使用更加友好。也因此，大多數開放原始碼授權都屬於這類，在2020年佔了76%。一種常用的寬鬆授權是MIT授權，通常因其簡短的性質而被選擇。該授權給予使用者使用該軟體的完全授權，唯一的要求是在釋出軟體時必須包含授權說明和版權宣告。
Copyleft授權，最常見的是通用公眾授權（GPL）各版本所使用，當在商業軟體程式庫內使用時會產生風險，因為它可能會導致整套軟體的智慧財產權問題。因此，許多組織將系統內的GPL授權相關風險級別預設為高。
近來，因為眾多開放原始碼授權的出現，因為大型企業會使用開放原始碼來推出商業服務，利用開放原始碼來賺錢，所以出現了一個新的類別。這第三類稱為可取得原始碼（source available），儘管它類似於開放原始碼，但技術上有所不同，因為會加上額外限制來防止商業利用。也就是說，它讓作者能夠出於協作目的來公開分享程式碼，但防止被用於商業服務。
當開發人員使用可能存在授權問題的開放原始碼時，就需要進行風險評估。接著團隊必須決定是否可以解決程式碼相關責任問題，或是否需要進行修改來加以刪除。不過這樣做會導致延後程式推出的時間。因為這樣，組織的法律團隊通常有針對開放原始碼授權預先制定的準則。
沒有授權的開放軟體呢，那是免費的嗎？
簡單地說，不是。軟體預設會受著作權保護，未經授權，使用就是非法的，即便它被稱為開放原始碼。授權提供了使用、複製、派送或修改軟體的許可，在滿足條款的前提下才沒有侵權的風險。
客製化的開放原始碼授權
開發人員有時會撰寫自己的授權條款或更動標準授權的條款。儘管出發點通常是好的，但也容易起爭議。有一些相當瘋狂的授權，如Beerware授權，基本上是說如果你喜歡這款軟體，作為回報，你應該給作者買一杯啤酒，或者以他們的名義喝酒。另一個是小雞舞（Chicken Dance）授權，透過分享你跳小雞舞的影片來代替GPL的標準要求（分享你的程式碼）。
另一個更動標準授權的例子是JavaScript Object Notation的JSON授權，一種常見的資料交換元件。它修改了標準的MIT授權，增加了一個條款：「軟體應用於善，而不為惡」。這立意肯定是良善，但許多公司會選擇不接受，因為「善」和「惡」被認為是可隨人解釋的。
每家公司都必須決定自己的風險承受度，來選擇能接受哪些類型的授權。不過通常條款越模糊，從法律角度來看就越值得擔心。所以這類客製化授權通常不受歡迎，或直接會被公司的開放原始碼政策禁止使用。
開發人員不是該知道自己所使用的程式碼規範？
開發人員不是因為法律知識而被聘請的。他們的目標是創新、開發快且好。
重要的是要記住，開放原始碼是「免費」的誤解由來已久，最早可追溯到1985年，因此很難改觀。最初，它被稱為「自由軟體（Free Software）」，來自於推動可自由了解和修改軟體的自由軟體活動。
因此，開發人員出現此種誤解是可以理解的。他們所知道跟進行的是開發，而非相關的法律要求。而且許多公司在擴大開發內部應用程式時，可能沒有進行相關訓練或了解正在使用的開放原始碼。
授權條款通常也不是很直觀。以JSON為例 – 開發人員可能會認為沒有問題，因為他們只是在開發商業軟體，而非惡意軟體或任何「用於作惡」的東西，所以很快就跳過了。但律師可以從條款的模糊性中看出風險，並適當地關聯授權風險狀況。為了幫助減少授權風險，許多組織確實讓他們的開發人員接受了開放原始碼法律訓練。
相依性開放原始碼的授權悖論
以今日開發人員的開發速度，以及所使用的無數程式碼資源，要做好風險和責任管理幾乎是不可能。更不用說資安團隊對開發管道的低能見度。隨著開放原始碼的使用，更大的困難是缺乏對間接相依性的能見度。當開發人員使用與多個其他開放原始碼有相依性的開放原始碼元件時，會發生什麼事？這看起來有點像是無限悖論效應，對吧？因為你不僅要對有直接相依性的授權條款負責，還要對任何開發時用到開放原始碼元件所帶來的間接相依性負責。
開放原始碼授權影響你軟體供應鏈的完整性
供應鏈攻擊是許多IT團隊的頭等大事，其中一個重要難題是確保其完整性。而合規性是其中的關鍵部分，也因此，Linux基金會等組織會尋求解決方案。OpenChain專案是作為軟體供應鏈裡開放原始碼授權合規性的有效認證而建立。它所做的就是強化整個供應鏈和確保每個環節都可以信任並滿足認證所需的合規標準。最新的OpenChain規範是ISO/IEC 5230:2020：「規範了高品質開放原始碼授權合規計劃的關鍵需求，以提供一個基準讓組織交換由開放原始碼組成的軟體解決方案時能互相信任。」
那要如何才能跟上並減少法律風險呢？
有些軟體具備擁有預先填入風險檔案的授權資料庫。法律團隊可以設定自動標記任何有授權衝突的開放原始碼。這些軟體擁有的開放原始碼資料庫包含了數千筆授權和授權系列。這些軟體也會幫你追蹤組織正在使用的授權，然後建立包含所有授權的報告，用來包進要推出的應用程式。訓練開發人員了解開放原始碼相關法律也是種重要的應對措施，因為這有助於減少潛在問題。
趨勢科技的Cloud One – Open Source Security由包含數千筆開放原始碼及相關授權的Snyk資料庫所驅動。此解決方案涵蓋了開放原始碼的兩種常見風險（漏洞和授權），讓你可以從單一主控台來控制和減少所有開放原始碼的風險。這為資安和營運團隊帶來了重要的價值，透過進一步提高對開發管道所用程式庫的能見度來管理開放原始碼使用的風險和責任。Cloud One – Open Source Security可協助資安和法律團隊在軟體開發生命週期的早期就識別出風險，與應用程式推出給客戶後才發現相比，能夠省下昂貴的修復代價（時間和費用）。