企業(yè)開源指南:開源代碼的使用
時間:2023-05-04 12:48:01 | 來源:網(wǎng)站運營
時間:2023-05-04 12:48:01 來源:網(wǎng)站運營
企業(yè)開源指南:開源代碼的使用:
開源項目辦公室最重要的責任之一,是要在整合開源代碼與專有的、第三方的源代碼到商業(yè)產(chǎn)品中時,確保您的組織符合其法定義務。 轉(zhuǎn)自: https://linuxfoundation.cn/using-open-source-code/
作者/來源: Todo
最大限度優(yōu)化組織中運行開源計劃或啟動開源項目的實踐。這些資源由 Linux 基金會與 TODO Group 合作開發(fā),代表了我們的員工、項目和成員的經(jīng)驗。
- 英文: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
開源項目辦公室最重要的責任之一,是要在整合開源代碼與專有的、第三方的源代碼到商業(yè)產(chǎn)品中時,確保您的組織符合其法定義務。
您需要制定有關開發(fā)人員如何使用開源代碼,以及追蹤開源代碼的來源、授權方式及其最終結(jié)果的詳細流程指南。本指南讓您從一個基準的合規(guī)項目開始,來使用、發(fā)布和分發(fā)開源代碼。
本指南的撰稿人
- Ibrahim Haddad - 三星美國研究院研發(fā)副總裁兼開源小組負責人
為何追蹤并審查代碼
簡單來說,如果您的公司沒有追蹤開發(fā)人員如何使用開源代碼的方式和地點,那么您將面臨不遵守適用開源許可證的風險——無論是在法律費用和修正錯誤所花費的工程時間兩個方面都是一種昂貴的途徑。忽視開源法律義務也會影響貴公司在開源社區(qū)的聲譽。
開源項目辦公室?guī)椭兄贫▏@開源消費、分發(fā)和發(fā)布來集中制定方針和政策,追蹤代碼來源及其使用情況,并確保組織不違反其合規(guī)義務。
理想情況下,開源項目包含一個在法律顧問的幫助下開發(fā)的完整的合規(guī)項目。在本指南中,我們將介紹合規(guī)項目的一個重要方面:您關于使用、發(fā)布和分發(fā)開源代碼的方針與流程。
“一個精心設計的開源合規(guī)流程應同時確保遵守開源許可證條款,并幫助企業(yè)保護自己的知識產(chǎn)權,以及第三方供應商免受意外披露和/或其他后果的影響?!?
Ibrahim Haddad – 三星美國研究院研發(fā)副總裁兼開源小組負責人
企業(yè)可以通過維護開源合規(guī)項目獲得幾點好處:
- 獲得技術優(yōu)勢——因為兼容的軟件組合更易于服務、測試、升級和維護。
- 識別開源代碼部分——將發(fā)現(xiàn)在多個產(chǎn)品和組織的某些部分使用了哪些代碼,且/或?qū)﹂_源戰(zhàn)略是具有高度戰(zhàn)略價值和益處。
- 說明與使用開源組件相關的成本與風險——當代碼經(jīng)過多輪審查時,這將是顯而易見的。
- 建立社區(qū)信任——如果發(fā)生合規(guī)性挑戰(zhàn),這樣的項目可以展示一個正在進行的善意行為模式。
- 為適合收購、銷售或者新產(chǎn)品或服務的發(fā)布做好準備——這是一種罕見的好處,但在完成此類交易之前,合規(guī)性保證是強制性的。
- 建立供應鏈可信度——可以提高整個軟件供應鏈的合規(guī)性,包括提升原始設備制造商(OEM)和下游供應商的合規(guī)性。
合規(guī)角色與責任
在開源計劃中,需要創(chuàng)建一個特定的開源合規(guī)團隊,該團隊的任務是確保開源的合規(guī)性。
這個核心團隊,通常被稱為
審計團隊或開源審查委員會(Open Source Review Board)(OSRB),由來自工程團隊和產(chǎn)品團隊的代表,一名或多名法律顧問以及
合規(guī)人員(Compliance Officer)組成(合規(guī)人員通常是開源項目經(jīng)理)。
各個部門中的其他人員也為開源合規(guī)工作提供源源不斷的基礎:文件、供應鏈、企業(yè)開發(fā)、IT、本地化和監(jiān)督整個開源戰(zhàn)略的
開源執(zhí)行委員會(Open Source Executive Committee)(OSEC)。但與核心團隊不同,這些擴展團隊的成員只是根據(jù)從開源審查委員會(OSRB)收到的任務,在兼職的基礎上開展工作。
開源審查委員會(OSRB)負責創(chuàng)建開源合規(guī)戰(zhàn)略和一套決定企業(yè)如何在日常基礎上實施這些規(guī)則的流程。該戰(zhàn)略確立了必須采取的措施來保證合規(guī)性,并為員工如何與開源軟件進行互動提供了一套主要原則。它包括了開源的審批、獲取與使用的正式流程,以及發(fā)布開源軟件或經(jīng)開源許可證授權的軟件。
使用開源代碼的一個簡單方針
使用辦法是所有合規(guī)項目的重要組成部分。這套規(guī)則包含在您的開源戰(zhàn)略文件中(您有一份開源戰(zhàn)略文件,對嗎?),并提供給所有人以便參考。
使用辦法確保任何成為產(chǎn)品基礎的(專有的、第三方的或開源的)軟件都已經(jīng)過審核、審查與審批。該辦法還確保在產(chǎn)品送達客戶之前,貴公司已經(jīng)制定了一個計劃來履行因使用各種軟件組件所產(chǎn)生的許可證義務。
無需制作一份冗長或復雜的文件。一個優(yōu)秀的開源使用辦法包括六個簡單規(guī)則:
- 在將開源代碼整合到產(chǎn)品中之前,工程師必須獲得開源審查委員會(OSRB)的許可。
- 從第三方接收的軟件必須經(jīng)過審核,以識別其包含的所有開源代碼,這樣可以確保在產(chǎn)品發(fā)貨之前許可證的義務得以履行。
- 所有軟件都必須經(jīng)過審核和審查,包括所有的專有軟件組件。
- 產(chǎn)品必須在客戶收貨前履行開源許可證義務。
- 即使開源組件是一樣的,對于在一個產(chǎn)品中使用給定的開源組件的許可也不等于其他部署許可。
- 任何變更的組件都必須經(jīng)過審批流程。
代碼審查過程的五個階段
一旦制定辦法,就必須計劃并創(chuàng)建一個更易于應用辦法中規(guī)定的流程。您的工作是幫助開發(fā)人員順利地進行開源應用并為開源項目做貢獻。
“如果您的代碼審查過程過于繁瑣,您將會放慢創(chuàng)新的進程,或是為開發(fā)人員完全規(guī)避流程提供好借口?!?br>Ibrahim Haddad – 三星美國研究院研發(fā)副總裁兼開源小組負責人
該過程首先掃描有問題的軟件包的源代碼,然后繼續(xù)識別并解決所有發(fā)現(xiàn)的問題,還進行法律和體系構架的審查,并就相關使用許可做出決定。
下圖展示了一個合規(guī)使用過程的簡單視圖。實際上,這個過程本質(zhì)上更具有迭代性。請記住,這些階段僅適用于說明目的,可能需要根據(jù)公司自身需求和開源項目配置進行相應的修改。
讓我們來看看這個過程中的每個階段。
階段 1:源代碼掃描
在源代碼掃描階段,所有源代碼都被專門的軟件工具掃描(除了一些開源替代品之外,還有許多商業(yè)供應商提供這種工具)。
當工程師提交線上使用表單時,此階段通常會啟動。(請參閱下文的示例的使用表單和使用規(guī)則)該表單包含了關于有問題的開源組件的所有信息,并指定了源代碼在源代碼庫系統(tǒng)中的位置。
表單提交后會自動在JIRA或Bugzilla等系統(tǒng)中創(chuàng)建合規(guī)工單,并將源代碼掃描請求發(fā)送給指定的審計人員。定期的全平臺掃描也應該每幾周進行一次,以確保無開源軟件組件被整合到平臺上卻沒有相應的表單。如果發(fā)現(xiàn)任何問題,那么JIRA工單將自動發(fā)出并分配給審計人員。
可觸發(fā)源代碼掃描的因素包括:
- 一份傳入的使用表單,通常是由工程人員填寫的。
- 定期安排全平臺掃描。這樣的掃描對于發(fā)現(xiàn)隱藏在軟件平臺中而無使用表單的開源代碼非常有用。
- 更改先前批準的軟件組件。在很多情況下,工程師使用特定版本的 OSS 組件來開始評估和測試工作,并在新版本可用時采用該組件。
- 源代碼是從第三方軟件供應商處獲得的,該供應商可能會也可能不會披露開源。
- 源代碼是從未知作者和/或許可證的網(wǎng)頁上下載的,它可能有也可能沒有開源代碼。
- 一個新的專有軟件組件進入開發(fā)系統(tǒng),在系統(tǒng)中工程可能有也可能沒有借用開源代碼并將其用于專有軟件組件。
代碼被掃描后,掃描工具會生成一份報告,其中提供以下列信息:
- 已知在用的軟件組件,也被稱為軟件物料清單(BoM)
- 有效的許可證、許可證文本和義務概述
- 須經(jīng)法律驗證的許可證沖突
- 文件清單
- 識別的文件
- 依賴性
- 代碼匹配
- 待識別文件
- 源代碼匹配待定標識
關于下載的開源軟件包的說明:
將從網(wǎng)頁上下載的開源軟件包歸檔到原始表單中是至關重要的。這些軟件包將被應用于之后階段中(在分發(fā)階段之前),通過計算原始軟件包和修改后的軟件包之間的差異,來驗證并追蹤引入源代碼中的所有變更。
如果第三方軟件供應商使用了開源軟件,則將該代碼整合到產(chǎn)品中的產(chǎn)品團隊必須提交一個開源使用表單來說明所使用的開源代碼。如果第三方軟件供應商僅提供二進制代碼,而不提供源代碼,那么負責管理第三方軟件供應商關系的產(chǎn)品團隊和/或軟件供應商經(jīng)理必須取得在供應商所提供的軟件中沒有開源代碼的確認(例如,掃描報告)。
階段 2 :識別和解決
在識別和解決階段,審計團隊需檢查并解析由掃描工具標記的每個文件或摘錄。
例如,掃描工具的報告可以標記諸如沖突和不兼容許可證等問題。如果沒有問題,則合規(guī)辦公室會將合規(guī)票據(jù)轉(zhuǎn)移到法律審查階段。
如果有問題需要解決,那么合規(guī)人員會在合規(guī)票據(jù)中創(chuàng)建子任務,并將其分配給相應的工程師來解決。在某些情況下,代碼返工是必要的;在其他情況下,這可能只是一個澄清事宜。這些子任務應包括問題描述、由工程團隊實施的建議解決方案,以及具體的完成時間表。
一旦所有問題都得到解決,合規(guī)人員可以簡單地關閉子任務,然后將票據(jù)傳至法律審查階段?;蛘?,他們可能會首先下令重新掃描源代碼,并生成一份新的掃描報告,以確認之前的問題已不存在。一旦他們確信所有問題都已經(jīng)得到解決,合規(guī)人員會將合規(guī)票據(jù)轉(zhuǎn)發(fā)給法律部門的代表進行審查和批準。
在準備進行法律審查時,您應該將與開源軟件相關的所有許可證信息添加到合規(guī)票據(jù)中,例如 COPYING(版權文件)、README(自述文件)、LICENSE(許可證文件)等。
階段 3:法律審查
在法律審查期間,法律顧問需要決定出入許可證:
準入許可證 = 專有許可證 + 許可證 A + 許可證 B + 許可證 C
準出許可證 = ?
- 有問題:
如發(fā)現(xiàn)許可證有問題,例如具有不兼容許可證的混合源代碼,法律顧問將標記這些問題并重新分配JIRA中的合規(guī)工單給工程師以重新編寫代碼。
例如,在法律審查中可能會發(fā)現(xiàn),密切關注的知識產(chǎn)權已經(jīng)與開源代碼包相結(jié)合。法律顧問將對此進行標記,并將合規(guī)票據(jù)重新分配給工程師以從開源組件中移除專有源代碼。如果工程師堅持將專有源代碼保留在開源組件中,開源執(zhí)行委員會(OSEC)將需要根據(jù)開源許可證來發(fā)布專有源代碼。 - 不確定是否有問題:
在某些情況下,如果許可證信息是不清楚或者是無法獲得的,法律顧問或工程人員要聯(lián)系項目維護人員或開發(fā)人員,以澄清歧義之處并確認特定的軟件組件是由哪個許可證所授權的。
階段 4 :結(jié)構審查
在結(jié)構審查中,合規(guī)人員和來自審計團隊的工程代表或開源審查委員會對開源代碼、專有代碼和第三方代碼之間的相互作用進行分析。這是通過測試識別以下內(nèi)容的架構圖(參見以下示例)來實現(xiàn)的:
- 開源組件(“按原樣”使用或修改后使用)
- 專有組件
- 來自第三方軟件供應商的組件
- 組件依賴性
- 通信協(xié)議
- 特定軟件組件相互作用或取決其他開源代碼包,尤其是當它由不同的開源許可證管理時
結(jié)構審查的結(jié)果是對許可證的責任分析,許可證義務范圍可能從開源軟件組件擴展到專有代碼或是第三方軟件組件(以及還有跨開源組件)。
如果合規(guī)人員發(fā)現(xiàn)任何問題,例如鏈接到 GPL 許可證組件的專有軟件組件,那么他們會將合規(guī)工單轉(zhuǎn)發(fā)給工程師們以解決相應問題。如果沒有問題,合規(guī)人員則將審批過程中的票據(jù)轉(zhuǎn)移到最后階段。
階段 5 :最終審查
最終審查通常是審計團隊或開源審查委員會(OSRB)的面談會議,在會議期間,該團隊批準或拒絕軟件組件的使用。
該團隊根據(jù)軟件組件完整的合規(guī)記錄來做決定,該記錄包括以下內(nèi)容:
- 一份由掃描工具生成的源代碼報告。
- 發(fā)現(xiàn)問題清單,關于問題如何解決的答案,以及由誰驗證解決了這些問題
- 架構圖和關于軟件組件如何與其他軟件組件相互作用的信息。
- 關于合規(guī)性的法律意見,以及出入許可證決定。
- 如果適用于嵌入式環(huán)境(C 語言/C++ 語言),則進行動態(tài)和靜態(tài)鏈接分析。
在大多數(shù)情況下,如果一個軟件組件到達最終審查階段,它將被批準,除非特殊情況出現(xiàn)(例如不再使用該軟件組件)。一旦獲得批準,合格職員將為被批準的軟件組件準備許可證義務清單,并將其交給合適的部門來履行義務。
這份清單可以包括:
- 更新軟件清單,以此來反映特定的 OSS 軟件組件版本 x 已被批準在產(chǎn)品 y 的版本 z 中使用。
- 向文件團隊發(fā)出工單,讓他們更新產(chǎn)品文件中的最終用戶注意事項,以反映產(chǎn)品或服務正在應用開源代碼。
- 在產(chǎn)品發(fā)貨前觸發(fā)分發(fā)流程。
Steps accomplished after the OSRB approval合規(guī)人員監(jiān)測所有開放工單,并確保在產(chǎn)品發(fā)貨或服務發(fā)起時完成工單。
有關更詳細的使用過程和可能場景,請參閱我們的電子書《企業(yè)中的開源合規(guī)性》。
在 1.0 版本之后該做什么
初始合規(guī)性,也稱基準合規(guī)性,在開發(fā)伊始時發(fā)生,并一直持續(xù)到第一版產(chǎn)品的發(fā)布。合規(guī)團隊識別軟件基線中包含的所有開源代碼,并通過前文概述的五階段批準流程,驅(qū)動所有源組件。
“關鍵是要記住,開源合規(guī)性不會隨著1.0版本的發(fā)布而停止。”
Ibrahim Haddad – 三星美國研究院研發(fā)副總裁兼開源小組負責人
一旦產(chǎn)品發(fā)貨,您將還需要開發(fā)一個增量合規(guī)流程來檢查源代碼。當開發(fā)從包含附加功能和/或漏洞修復的新分支開始時,這個流程就開始了。
增量合規(guī)流程是當產(chǎn)品功能被添加到基準版本 1.0 時,合規(guī)性被維護所通過的流程。
增量合規(guī)與建立基準合規(guī)性所需要的努力相反,增量合規(guī)性只需要相對相對簡單的工作。但仍然可能出現(xiàn)一些挑戰(zhàn)。您必須正確識別在版本 1.0 和版本 1.1 之間發(fā)生變更的源代碼,并且驗證版本之間的合規(guī)性增量:
- 已引進新軟件組件。
- 已停用現(xiàn)有軟件組件。
- 現(xiàn)有軟件組件可能已升級到較新的版本。
- 軟件組件許可證可能在不同版本間發(fā)生了變化。
- 現(xiàn)有的軟件組件可能會有關于漏洞修復的代碼變更,或功能和架構的變更。
一個顯而易見的問題是:我們該如何保持追蹤這些變化?答案很簡單:
物料清單(Bill Of Material)(BOM)差異工具。給定產(chǎn)品 1.1 版本的物料清單和 1.0 版本的物料清單,我們計算增量而后工具的輸出結(jié)果如下:
- 在1版本中添加的新軟件組件的名稱
- 更新軟件組件名稱
- 舊版軟件組件名稱
掌握這些信息后,實現(xiàn)增量合規(guī)性將成為一項相對容易的任務:
- 將新的軟件組件輸入到五階段的使用審批過程中。
- 在變更的軟件組件中逐行計算源代碼差異,并決定您想要再次掃描源代碼還是依賴先前的掃描結(jié)果。
- 通過移除不再使用的軟件組件來更新軟件注冊表。
下面的圖表提供了增量合規(guī)性流程的概述。每個產(chǎn)品版本的物料清單文件都存儲在構建服務器上。物料清單差異工具將兩個物料清單文件作為輸入,每個文件對應于不同的產(chǎn)品版本,并計算增量來生成如前所述的變更清單。
此時,合規(guī)人員將為該版本中所有新版軟件組件創(chuàng)建新的合規(guī)工單,更新源代碼發(fā)生變更的合規(guī)工單,并可能通過這一過程重新傳送,最后更新軟件注冊表,從批準清單中刪除已退休的軟件組件。
增量合規(guī)流程示例開源使用請求表單
完成開源使用請求表單是開發(fā)人員將開源軟件引入貴公司的重要步驟,應作嚴肅對待。
開發(fā)人員填寫在線表單,請求批準使用既定的開源組件。該表單包含若干將為審計團隊或開源審查委員會提供必要信息的問題,以讓他們批準或不批準所提議的開源組件的使用。
下面的表單突出顯示了開源使用請求表單中所要求的信息。這些數(shù)值通常是從下拉菜單中選擇的,以使數(shù)據(jù)輸入更高效。
管理開源審查委員會的使用表單有幾條規(guī)則,例如:
- 該表單僅適用于特定產(chǎn)品和環(huán)境的開源使用。這不是對于開源組件適用于所有產(chǎn)品中的所有用例的一般認可。
- 該表單是審計活動的基礎,同時提供審查團隊需要驗證的信息,團隊需要驗證實際履行是否與表單中表述的使用計劃一致,以及是否與審計和架構審查結(jié)果一致。
- 只要該特定開源組件的使用計劃發(fā)生變化,就必須更新表單并重新提交。
- 在工程師們整合開源組件到產(chǎn)品開發(fā)之前,審計團隊或?qū)彶槲瘑T會必須批準表單。
- 開源執(zhí)行委員會必須批準任何許可證條款要求授予專利許可或?qū)@羌m紛條款的開源軟件包的使用。
開源使用請求表單樣表:
結(jié)語
開源合規(guī)性是軟件開發(fā)過程的重要組成部分。如果您在產(chǎn)品中使用開源軟件,沒有一個可信賴的合規(guī)項目,那么您應該將本指南視為行動的號召。
從它的核心來說,開源合規(guī)性包括一系列控制商業(yè)產(chǎn)品中使用的開源的準入與分發(fā)行為。合規(guī)盡職調(diào)查的結(jié)果是對產(chǎn)品中所使用的所有開源識別(組件和代碼片段),以及滿足許可證義務的計劃。有關開源合規(guī)性的詳細指南,請下載我們的免費電子書,由 Ibrahim Haddad 所著的《企業(yè)中的開源合規(guī)性》。
架構圖模板
架構圖用于開源流程的結(jié)構審查階段,演示了示例平臺中軟件組件相互作用。這是一個示例架構圖,展示如下:
- 模塊依賴性
- 專有組件
- 開源組件(修改版與原版)
- 動態(tài)與靜態(tài)鏈接
- 內(nèi)核空間與用戶空間
- 共享頭文件
- 通信協(xié)議
問題軟件組件相互作用或依賴的其他開源組件,特別是如果它由不同的開源許可證管理時。
此架構圖模板適用于依賴 C 語言或 C++ 語言的嵌入式環(huán)境
TODO Group這些資源是與 TODO(Talk Openly,Develop Openly)組織合作創(chuàng)建的, 該組織是 Linux 基金會中專業(yè)的開源網(wǎng)絡組織。特別感謝奉獻自己的時間和知識來制作這些綜合指南的開源項目負責人。參與制作的公司包括 Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath(Yahoo + AOL)、Red Hat、Salesforce、Samsung 和 VMware。如想了解更多信息,請訪問:todogroup.org