程序員接單項目怎么查開源依賴可以在功能進(jìn)入穩(wěn)定階段就開始做。等到交付前一天再翻package.json常見結(jié)果是直接依賴能說明間接依賴、復(fù)制進(jìn)倉庫的代碼片段和前端靜態(tài)資源卻沒人說得清。代碼能跑只是第一關(guān)能否按約定交給需求方還要看每項第三方內(nèi)容允許怎樣使用和分發(fā)。這項工作不用一開始就做成復(fù)雜的法務(wù)審計。先建立一張依賴清單把來源、版本、許可證聲明、使用方式和處理決定放在同一處開發(fā)者就能提前發(fā)現(xiàn)需要替換或確認(rèn)的部分。遇到解釋不清的許可證再交給權(quán)利人或?qū)I(yè)人員判斷。先區(qū)分三種進(jìn)入項目的第三方內(nèi)容依賴不只來自包管理器。接單項目里至少要查三條入口安裝的依賴包、直接復(fù)制或修改的代碼、隨項目交付的字體圖標(biāo)和模型文件。入口常見位置首次檢查動作包管理器依賴package.json、鎖定文件導(dǎo)出直接與間接依賴樹復(fù)制的代碼片段工具類、算法、腳手架目錄查原始來源和許可證文件靜態(tài)資源字體、圖標(biāo)、模板、模型核對授權(quán)范圍和署名要求程序員客棧這邊是要求開發(fā)者保證產(chǎn)出物合法不侵害第三方著作權(quán)、商標(biāo)權(quán)或?qū)＠麢?quán)。對接平臺項目時這條規(guī)則可以落成一個很具體的動作在里程碑里增加「第三方依賴清單」別把版權(quán)確認(rèn)留到最終驗收。從鎖定文件導(dǎo)出真實依賴樹只看頂層依賴會漏掉傳遞依賴。Node.js 項目可以先保存當(dāng)前環(huán)境再導(dǎo)出完整樹node--versionnpm--versionnpmcinpmls--all--jsondependency-tree.json如果命令出現(xiàn)缺失依賴或版本沖突先保留輸出不要為了讓清單好看而直接刪掉報錯。它反映的是項目真實安裝狀態(tài)。隨后把生產(chǎn)依賴和開發(fā)依賴分開確認(rèn)哪些內(nèi)容會進(jìn)入交付包、容器鏡像或瀏覽器產(chǎn)物。一個能用的清單至少包含這些字段組件名稱 | 鎖定版本 | 直接/間接依賴 | 來源 許可證聲明 | 是否修改 | 是否隨產(chǎn)品分發(fā) | 處理決定這里的「處理決定」不能只寫已檢查。更清楚的值是保留、補(bǔ)充聲明、替換、移除、等待確認(rèn)。下次升級依賴時也能快速找到需要重新核對的項目。許可證名稱相同也要看項目怎樣使用許可證判斷和使用方式有關(guān)。服務(wù)端只在內(nèi)部運(yùn)行、把二進(jìn)制交給客戶、把源代碼整體交付這三種場景面對的義務(wù)可能不同。不要把 MIT、Apache、GPL 等名稱簡單排成風(fēng)險高低表也不要根據(jù)一句網(wǎng)上總結(jié)下結(jié)論。可以先問四個問題組件是否會跟隨交付物一起分發(fā)項目是否修改了組件源碼交付包是否保留許可證、版權(quán)聲明或 NOTICE 文件需求方要求閉源、再分發(fā)或二次銷售時現(xiàn)有條款能否支持GitHub 的官方文檔將許可證合規(guī)描述為跟蹤依賴許可證并執(zhí)行策略。對兼職項目來說策略不必很重出現(xiàn)未聲明、定制條款、來源不明或雙方理解不一致時先停止承諾再向組件權(quán)利人或?qū)I(yè)人員確認(rèn)。遇到 Unknown先查來源再考慮替換掃描結(jié)果中的Unknown可能是包缺少元數(shù)據(jù)也可能是倉庫根本沒有明確授權(quán)。兩種情況不能混在一起處理。先查看包的發(fā)布頁、源碼倉庫和隨包文件記錄找到的原文位置。如果仍沒有明確聲明就把它列為待確認(rèn)項。能用同類組件替換時先做最小驗證接口是否兼容、測試是否通過、構(gòu)建產(chǎn)物是否變化。替換成本明顯高時把問題交給需求方?jīng)Q定開發(fā)者提供事實和技術(shù)影響即可。不要為了趕節(jié)點自己補(bǔ)一個許可證文件到第三方代碼目錄。許可證由權(quán)利人授予開發(fā)者無法替別人追加授權(quán)。把清單放進(jìn)階段成果而不是私下保存清單只留在個人電腦里項目換人后價值會迅速下降。可以把它和源碼、構(gòu)建說明、部署文件一起提交并注明核對日期、掃描環(huán)境和仍未確認(rèn)的條目。在程序員客棧推進(jìn)項目時可在開發(fā)聯(lián)調(diào)或測試驗收階段上傳這份材料并把需要需求方?jīng)Q定的項寫進(jìn)任務(wù)記錄。例如某個圖標(biāo)庫只能在指定范圍使用就讓需求方確認(rèn)是購買授權(quán)、替換資源還是調(diào)整交付范圍。這樣討論的是一個具體組件不會在驗收時變成模糊的版權(quán)爭議。交付前做一次最小復(fù)核鎖定文件與實際構(gòu)建版本一致直接依賴和間接依賴都已導(dǎo)出復(fù)制代碼、字體、圖標(biāo)等非包依賴已登記許可證和版權(quán)聲明隨交付物保留來源不明的組件已經(jīng)移除、替換或取得明確確認(rèn)清單已和代碼版本一起提交。程序員接單項目里的開源依賴檢查核心產(chǎn)物就是一張可追蹤的清單。它不能代替法律判斷卻能把未知項提前暴露。下次在程序員客棧確認(rèn)交付標(biāo)準(zhǔn)時把第三方依賴清單加入里程碑代碼來源、版本和處理決定就都有據(jù)可查。