開源項目辦公室最重要的責任之一，是要在整合開源代碼與專有的、第三方的源代碼到商業產品中時，確保您的組織符合其法定義務。

轉自： https://linuxfoundation.cn/using-open-source-code/

作者/來源： Todo

最大限度優化組織中運行開源計劃或啟動開源項目的實踐。這些資源由 Linux 基金會與 TODO Group 合作開發，代表了我們的員工、項目和成員的經驗。

• 英文： https://todogroup.org/guides/using-open-source/
• 中文： https://linuxfoundation.cn/using-open-source-code/
• GitHub： https://github.com/todogroup/todogroup.github.io/blob/master/content/en/guides/using-open-source.md

開源項目辦公室最重要的責任之一，是要在整合開源代碼與專有的、第三方的源代碼到商業產品中時，確保您的組織符合其法定義務。

您需要制定有關開發人員如何使用開源代碼，以及追蹤開源代碼的來源、授權方式及其最終結果的詳細流程指南。本指南讓您從一個基準的合規項目開始，來使用、發布和分發開源代碼。

本指南的撰稿人

• Ibrahim Haddad - 三星美國研究院研發副總裁兼開源小組負責人

為何追蹤並審查代碼

簡單來說，如果您的公司沒有追蹤開發人員如何使用開源代碼的方式和地點，那麼您將面臨不遵守適用開源許可證的風險——無論是在法律費用和修正錯誤所花費的工程時間兩個方面都是一種昂貴的途徑。忽視開源法律義務也會影響貴公司在開源社區的聲譽。

開源項目辦公室幫助集中制定圍繞開源消費、分發和發布來集中制定方針和政策，追蹤代碼來源及其使用情況，並確保組織不違反其合規義務。

理想情況下，開源項目包含一個在法律顧問的幫助下開發的完整的合規項目。在本指南中，我們將介紹合規項目的一個重要方面：您關於使用、發布和分發開源代碼的方針與流程。

「一個精心設計的開源合規流程應同時確保遵守開源許可證條款，並幫助企業保護自己的知識產權，以及第三方供應商免受意外披露和/或其他後果的影響。」

Ibrahim Haddad – 三星美國研究院研發副總裁兼開源小組負責人

企業可以通過維護開源合規項目獲得幾點好處：

• 獲得技術優勢——因為兼容的軟體組合更易於服務、測試、升級和維護。
• 識別開源代碼部分——將發現在多個產品和組織的某些部分使用了哪些代碼，且/或對開源戰略是具有高度戰略價值和益處。
• 說明與使用開源組件相關的成本與風險——當代碼經過多輪審查時，這將是顯而易見的。
• 建立社區信任——如果發生合規性挑戰，這樣的項目可以展示一個正在進行的善意行為模式。
• 為適合收購、銷售或者新產品或服務的發布做好準備——這是一種罕見的好處，但在完成此類交易之前，合規性保證是強制性的。
• 建立供應鏈可信度——可以提高整個軟體供應鏈的合規性，包括提升原始設備製造商（OEM）和下游供應商的合規性。

合規角色與責任

在開源計劃中，需要創建一個特定的開源合規團隊，該團隊的任務是確保開源的合規性。

這個核心團隊，通常被稱為 審計團隊或開源審查委員會(Open Source Review Board)（OSRB），由來自工程團隊和產品團隊的代表，一名或多名法律顧問以及 合規人員(Compliance Officer)組成（合規人員通常是開源項目經理）。

各個部門中的其他人員也為開源合規工作提供源源不斷的基礎：文件、供應鏈、企業開發、IT、本地化和監督整個開源戰略的 開源執行委員會(Open Source Executive Committee)（OSEC）。但與核心團隊不同，這些擴展團隊的成員只是根據從開源審查委員會（OSRB）收到的任務，在兼職的基礎上開展工作。

開源審查委員會（OSRB）負責創建開源合規戰略和一套決定企業如何在日常基礎上實施這些規則的流程。該戰略確立了必須採取的措施來保證合規性，並為員工如何與開源軟體進行互動提供了一套主要原則。它包括了開源的審批、獲取與使用的正式流程，以及發布開源軟體或經開源許可證授權的軟體。

使用開源代碼的一個簡單方針

使用辦法是所有合規項目的重要組成部分。這套規則包含在您的開源戰略文件中（您有一份開源戰略文件，對嗎？），並提供給所有人以便參考。

使用辦法確保任何成為產品基礎的（專有的、第三方的或開源的）軟體都已經過審核、審查與審批。該辦法還確保在產品送達客戶之前，貴公司已經制定了一個計劃來履行因使用各種軟體組件所產生的許可證義務。

無需製作一份冗長或複雜的文件。一個優秀的開源使用辦法包括六個簡單規則：

• 在將開源代碼整合到產品中之前，工程師必須獲得開源審查委員會（OSRB）的許可。
• 從第三方接收的軟體必須經過審核，以識別其包含的所有開源代碼，這樣可以確保在產品發貨之前許可證的義務得以履行。
• 所有軟體都必須經過審核和審查，包括所有的專有軟體組件。
• 產品必須在客戶收貨前履行開源許可證義務。
• 即使開源組件是一樣的，對於在一個產品中使用給定的開源組件的許可也不等於其他部署許可。
• 任何變更的組件都必須經過審批流程。

代碼審查過程的五個階段

一旦制定辦法，就必須計劃並創建一個更易於應用辦法中規定的流程。您的工作是幫助開發人員順利地進行開源應用並為開源項目做貢獻。

「如果您的代碼審查過程過於繁瑣，您將會放慢創新的進程，或是為開發人員完全規避流程提供好借口。「

Ibrahim Haddad – 三星美國研究院研發副總裁兼開源小組負責人

該過程首先掃描有問題的軟體包的源代碼，然後繼續識別並解決所有發現的問題，還進行法律和體系構架的審查，並就相關使用許可做出決定。

下圖展示了一個合規使用過程的簡單視圖。實際上，這個過程本質上更具有迭代性。請記住，這些階段僅適用於說明目的，可能需要根據公司自身需求和開源項目配置進行相應的修改。

讓我們來看看這個過程中的每個階段。

階段 1：源代碼掃描

在源代碼掃描階段，所有源代碼都被專門的軟體工具掃描（除了一些開源替代品之外，還有許多商業供應商提供這種工具）。

當工程師提交線上使用表單時，此階段通常會啟動。（請參閱下文的示例的使用表單和使用規則）該表單包含了關於有問題的開源組件的所有信息，並指定了源代碼在源代碼庫系統中的位置。

表單提交後會自動在JIRA或Bugzilla等系統中創建合規工單，並將源代碼掃描請求發送給指定的審計人員。定期的全平台掃描也應該每幾周進行一次，以確保無開源軟體組件被整合到平台上卻沒有相應的表單。如果發現任何問題，那麼JIRA工單將自動發出並分配給審計人員。

可觸發源代碼掃描的因素包括：

• 一份傳入的使用表單，通常是由工程人員填寫的。
• 定期安排全平台掃描。這樣的掃描對於發現隱藏在軟體平台中而無使用表單的開源代碼非常有用。
• 更改先前批准的軟體組件。在很多情況下，工程師使用特定版本的 OSS 組件來開始評估和測試工作，並在新版本可用時採用該組件。
• 源代碼是從第三方軟體供應商處獲得的，該供應商可能會也可能不會披露開源。
• 源代碼是從未知作者和/或許可證的網頁上下載的，它可能有也可能沒有開源代碼。
• 一個新的專有軟體組件進入開發系統，在系統中工程可能有也可能沒有借用開源代碼並將其用於專有軟體組件。

代碼被掃描後，掃描工具會生成一份報告，其中提供以下列信息：

• 已知在用的軟體組件，也被稱為軟體物料清單（BoM）
• 有效的許可證、許可證文本和義務概述
• 須經法律驗證的許可證衝突
• 文件清單
• 識別的文件
• 依賴性
• 代碼匹配
• 待識別文件
• 源代碼匹配待定標識

關於下載的開源軟體包的說明：

將從網頁上下載的開源軟體包歸檔到原始表單中是至關重要的。這些軟體包將被應用於之後階段中（在分發階段之前），通過計算原始軟體包和修改後的軟體包之間的差異，來驗證並追蹤引入源代碼中的所有變更。

如果第三方軟體供應商使用了開源軟體，則將該代碼整合到產品中的產品團隊必須提交一個開源使用表單來說明所使用的開源代碼。如果第三方軟體供應商僅提供二進位代碼，而不提供源代碼，那麼負責管理第三方軟體供應商關係的產品團隊和/或軟體供應商經理必須取得在供應商所提供的軟體中沒有開源代碼的確認（例如，掃描報告）。

階段 2 ：識別和解決

在識別和解決階段，審計團隊需檢查並解析由掃描工具標記的每個文件或摘錄。

例如，掃描工具的報告可以標記諸如衝突和不兼容許可證等問題。如果沒有問題，則合規辦公室會將合規票據轉移到法律審查階段。

如果有問題需要解決，那麼合規人員會在合規票據中創建子任務，並將其分配給相應的工程師來解決。在某些情況下，代碼返工是必要的；在其他情況下，這可能只是一個澄清事宜。這些子任務應包括問題描述、由工程團隊實施的建議解決方案，以及具體的完成時間表。

一旦所有問題都得到解決，合規人員可以簡單地關閉子任務，然後將票據傳至法律審查階段。或者，他們可能會首先下令重新掃描源代碼，並生成一份新的掃描報告，以確認之前的問題已不存在。一旦他們確信所有問題都已經得到解決，合規人員會將合規票據轉發給法律部門的代表進行審查和批准。

在準備進行法律審查時，您應該將與開源軟體相關的所有許可證信息添加到合規票據中，例如 COPYING（版權文件）、README（自述文件）、LICENSE（許可證文件）等。

階段 3：法律審查

在法律審查期間，法律顧問需要決定出入許可證：

准入許可證 = 專有許可證 + 許可證 A + 許可證 B + 許可證 C

准出許可證 = ？

• 有問題：
• 如發現許可證有問題，例如具有不兼容許可證的混合源代碼，法律顧問將標記這些問題並重新分配JIRA中的合規工單給工程師以重新編寫代碼。
• 例如，在法律審查中可能會發現，密切關注的知識產權已經與開源代碼包相結合。法律顧問將對此進行標記，並將合規票據重新分配給工程師以從開源組件中移除專有源代碼。如果工程師堅持將專有源代碼保留在開源組件中，開源執行委員會（OSEC）將需要根據開源許可證來發布專有源代碼。
• 不確定是否有問題：
• 在某些情況下，如果許可證信息是不清楚或者是無法獲得的，法律顧問或工程人員要聯繫項目維護人員或開發人員，以澄清歧義之處並確認特定的軟體組件是由哪個許可證所授權的。

階段 4 ：結構審查

在結構審查中，合規人員和來自審計團隊的工程代表或開源審查委員會對開源代碼、專有代碼和第三方代碼之間的相互作用進行分析。這是通過測試識別以下內容的架構圖（參見以下示例）來實現的：

• 開源組件（「按原樣」使用或修改後使用）
• 專有組件
• 來自第三方軟體供應商的組件
• 組件依賴性
• 通信協議
• 特定軟體組件相互作用或取決其他開源代碼包，尤其是當它由不同的開源許可證管理時

結構審查的結果是對許可證的責任分析，許可證義務範圍可能從開源軟體組件擴展到專有代碼或是第三方軟體組件（以及還有跨開源組件）。

如果合規人員發現任何問題，例如鏈接到 GPL 許可證組件的專有軟體組件，那麼他們會將合規工單轉發給工程師們以解決相應問題。如果沒有問題，合規人員則將審批過程中的票據轉移到最後階段。

階段 5 ：最終審查

最終審查通常是審計團隊或開源審查委員會（OSRB）的面談會議，在會議期間，該團隊批准或拒絕軟體組件的使用。

該團隊根據軟體組件完整的合規記錄來做決定，該記錄包括以下內容：

• 一份由掃描工具生成的源代碼報告。
• 發現問題清單，關於問題如何解決的答案，以及由誰驗證解決了這些問題
• 架構圖和關於軟體組件如何與其他軟體組件相互作用的信息。
• 關於合規性的法律意見，以及出入許可證決定。
• 如果適用於嵌入式環境（C 語言/C++ 語言），則進行動態和靜態鏈接分析。

在大多數情況下，如果一個軟體組件到達最終審查階段，它將被批准，除非特殊情況出現（例如不再使用該軟體組件）。一旦獲得批准，合格職員將為被批准的軟體組件準備許可證義務清單，並將其交給合適的部門來履行義務。

這份清單可以包括：

• 更新軟體清單，以此來反映特定的 OSS 軟體組件版本 x 已被批准在產品 y 的版本 z 中使用。
• 向文件團隊發出工單，讓他們更新產品文件中的最終用戶注意事項，以反映產品或服務正在應用開源代碼。
• 在產品發貨前觸發分發流程。

Steps accomplished after the OSRB approval

合規人員監測所有開放工單，並確保在產品發貨或服務發起時完成工單。

有關更詳細的使用過程和可能場景，請參閱我們的電子書 《企業中的開源合規性》 。

在 1.0 版本之後該做什麼

初始合規性，也稱基準合規性，在開發伊始時發生，並一直持續到第一版產品的發布。合規團隊識別軟體基線中包含的所有開源代碼，並通過前文概述的五階段批准流程，驅動所有源組件。

「關鍵是要記住，開源合規性不會隨著1.0版本的發布而停止。」

Ibrahim Haddad – 三星美國研究院研發副總裁兼開源小組負責人

一旦產品發貨，您將還需要開發一個增量合規流程來檢查源代碼。當開發從包含附加功能和/或漏洞修復的新分支開始時，這個流程就開始了。

增量合規流程是當產品功能被添加到基準版本 1.0 時，合規性被維護所通過的流程。

增量合規

與建立基準合規性所需要的努力相反，增量合規性只需要相對相對簡單的工作。但仍然可能出現一些挑戰。您必須正確識別在版本 1.0 和版本 1.1 之間發生變更的源代碼，並且驗證版本之間的合規性增量：

• 已引進新軟體組件。
• 已停用現有軟體組件。
• 現有軟體組件可能已升級到較新的版本。
• 軟體組件許可證可能在不同版本間發生了變化。
• 現有的軟體組件可能會有關於漏洞修復的代碼變更，或功能和架構的變更。

一個顯而易見的問題是：我們該如何保持追蹤這些變化？答案很簡單： 物料清單(Bill Of Material)（BOM）差異工具。給定產品 1.1 版本的物料清單和 1.0 版本的物料清單，我們計算增量而後工具的輸出結果如下：

• 在1版本中添加的新軟體組件的名稱
• 更新軟體組件名稱
• 舊版軟體組件名稱

掌握這些信息後，實現增量合規性將成為一項相對容易的任務：

• 將新的軟體組件輸入到五階段的使用審批過程中。
• 在變更的軟體組件中逐行計算源代碼差異，並決定您想要再次掃描源代碼還是依賴先前的掃描結果。
• 通過移除不再使用的軟體組件來更新軟體註冊表。

下面的圖表提供了增量合規性流程的概述。每個產品版本的物料清單文件都存儲在構建伺服器上。物料清單差異工具將兩個物料清單文件作為輸入，每個文件對應於不同的產品版本，並計算增量來生成如前所述的變更清單。

此時，合規人員將為該版本中所有新版軟體組件創建新的合規工單，更新源代碼發生變更的合規工單，並可能通過這一過程重新傳送，最後更新軟體註冊表，從批准清單中刪除已退休的軟體組件。

增量合規流程示例

開源使用請求表單

完成開源使用請求表單是開發人員將開源軟體引入貴公司的重要步驟，應作嚴肅對待。

開發人員填寫在線表單，請求批准使用既定的開源組件。該表單包含若干將為審計團隊或開源審查委員會提供必要信息的問題，以讓他們批准或不批准所提議的開源組件的使用。

下面的表單突出顯示了開源使用請求表單中所要求的信息。這些數值通常是從下拉菜單中選擇的，以使數據輸入更高效。

管理開源審查委員會的使用表單有幾條規則，例如：

• 該表單僅適用於特定產品和環境的開源使用。這不是對於開源組件適用於所有產品中的所有用例的一般認可。
• 該表單是審計活動的基礎，同時提供審查團隊需要驗證的信息，團隊需要驗證實際履行是否與表單中表述的使用計劃一致，以及是否與審計和架構審查結果一致。
• 只要該特定開源組件的使用計劃發生變化，就必須更新表單並重新提交。
• 在工程師們整合開源組件到產品開發之前，審計團隊或審查委員會必須批准表單。
• 開源執行委員會必須批准任何許可證條款要求授予專利許可或專利非糾紛條款的開源軟體包的使用。

開源使用請求表單樣表：

結語

開源合規性是軟體開發過程的重要組成部分。如果您在產品中使用開源軟體，沒有一個可信賴的合規項目，那麼您應該將本指南視為行動的號召。

從它的核心來說，開源合規性包括一系列控制商業產品中使用的開源的准入與分發行為。合規盡職調查的結果是對產品中所使用的所有開源識別（組件和代碼片段），以及滿足許可證義務的計劃。有關開源合規性的詳細指南，請下載我們的免費電子書，由 Ibrahim Haddad 所著的 《企業中的開源合規性》 。

架構圖模板

架構圖用於開源流程的結構審查階段，演示了示例平台中軟體組件相互作用。這是一個示例架構圖，展示如下：

• 模塊依賴性
• 專有組件
• 開源組件（修改版與原版）
• 動態與靜態鏈接
• 內核空間與用戶空間
• 共享頭文件
• 通信協議

問題軟體組件相互作用或依賴的其他開源組件，特別是如果它由不同的開源許可證管理時。

此架構圖模板適用於依賴 C 語言或 C++ 語言的嵌入式環境

TODO Group

這些資源是與 TODO（Talk Openly，Develop Openly）組織合作創建的， 該組織是 Linux 基金會中專業的開源網路組織。特別感謝奉獻自己的時間和知識來製作這些綜合指南的開源項目負責人。參與制作的公司包括 Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath（Yahoo + AOL）、Red Hat、Salesforce、Samsung 和 VMware。如想了解更多信息，請訪問： todogroup.org

點擊「了解更多」可訪問文內鏈接

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！