開場

您好。我是 Open Source Program Office TF。Linux 基金會正在運營一個名為 OpenChain 的專案，該專案旨在創建開源管理的標準規範。我們已經進行了大約 2 年的大型專案，將 OpenChain  專案中確定的規範應用於 LINE。結果，我們獲得了開源管理的國際標準 ISO/IEC 5230 的認證。

在這篇文章中，我首先將介紹 OpenChain 專案是什麼，然後說明我們為了將 OpenChain  規範應用於 LINE 所做的努力。此外，我們也將探討實施 OpenChain 規範對公司和開發人員的意義。我希望這篇分享 LINE 經驗的文章能夠讓開發人員重新認識到開源管理的重要性，並為從事開源管理工作的人提供參考資料。

---

OpenChain專案是什麼

在企業進行軟體開發時，完全依靠企業自身力量進行開發的情況是少見的。他們會利用開源軟體，也會利用外包服務，或者購買商業軟體。在這些情況下，往往並非獨立存在，因此在開發一個產品時，會有多種原始碼從多種途徑流入。這種情況在開發完成並分發產品時也是一樣的。比起直接向客戶提供軟體，更常見的是通過其他地方，甚至是非常複雜的途徑來傳遞產品。這種軟體開發和提供的整個過程被稱為"軟體供應鏈"。

OpenChain 專案的目標是 "定義開源管理的標準，使企業能夠在複雜的軟體供應鏈中有效地管理開源軟體"。

接下來，我將介紹 OpenChain 專案的規範，並探討實施這些規範後，企業和其成員可以獲得哪些效益。

規範介紹

OpenChain專案定義了開源合規的核心要求，並提供了遵守這些要求的指導方針。OpenChain 規範被設計為適用於所有規模和行業的企業，目前已經發布到 3.0 版本。在 LINE，我們根據專案進行時的最新版本，即 2.1 版本的規範進行了應用。

2.1 版本的規範定義了企業必須執行的六項核心要求，如下所示：

1. 建立開源管理程序
   1. 明確定義政策及其適用範圍，參與者的責任和角色
   2. 發布該政策及其目標和不遵守時的影響，以便所有參與者都能了解
   3. 建立決策程序，如審查和識別許可證義務
2. 定義相關工作並提供支持
   1. 建立能有效應對外部對開源相關問題的流程
   2. 提供足夠的資源以確保開源程序的順利運行
   3. 建立處理法律諮詢等問題的流程
3. 審核和批准開源內容
   1. 建立流程，以創建和管理包含每個開源組件和識別的許可證的BOM（Bill of Material）
   2. 開源負責人應管理一般的開源使用案例，並整理主要許可證的要求和注意事項，並在公司內部分享
4. 創建和傳遞合規產品
   1. 遵守識別的開源許可證的義務，創建、保存和傳遞合規產品（開源通知，要公開的源代碼包）
5. 了解開源社區的參與
   1. 將對開源專案的貢獻政策和流程文檔化
6. 遵守規範要求
   1. 滿足 OpenChain 規範的所有要求，並聲明公司有遵守 OpenChain 的程序

即使是剛開始開源治理的企業，也可以按照 OpenChain 規範的要求一步步建立高層的管理流程。

LINE 特別關注的部分

在應用上述規範時，我們特別關注了一些符合 LINE 組織特性的部分。讓我們一一來看。

比較 OpenChain 規範和現有的LINE政策

在開始 OpenChain 專案的階段，LINE已經根據過去的經驗和通過外部社群學習的內容，制定並實施了開源政策。因此，LINE 在開始 OpenChain 專案之前，首先確定了該專案所需的規範是什麼，並整理了里程碑。在整理里程碑的過程中，我們特別考慮並整理了以下幾點：

• 根據規範，我們已經做得很好的部分是什麼
• 根據規範，我們的不足之處是什麼
• 我們需要新建立什麼
• 是否有需要與其他部門協商的部分

確立內部傳播方法

OpenChain 規範不僅要求制定良好的政策，還要求將這些良好的政策和流程放在員工可以輕易接觸到的地方，並通過教育充分解釋。即使政策制定得再精巧，如果開發人員無法了解，也無法發揮其應有的效果。這一點是我們在進行開源管理工作時一直在思考和努力的部分，我們在考慮如何有效地傳播新的政策時再次思考了這一點。

我們將開源政策添加到了共享的開發治理規定中，以確保開發人員能隨時清楚地了解開源政策的存在。因此，只在分發過程中確認的開源政策變成了開發過程中必須確認的步驟。為了確保這種變化不會對現有的開發工作產生重大影響，我們提供了一份將常見的開源許可證分類並解釋的文件，讓開發人員可以自己輕鬆快速地進行判斷。當然，我們也在持續通過多種內部渠道宣傳開源政策的改變，並傳達改變的內容。

建立OSRB（Open Source Review Board）

在進行 OpenChain 專案的過程中，最困難的任務之一就是建立 OSRB。開源管理工作的基礎是自家開發的程序的開源合規性。在LINE，Open Source Program Office 不僅負責這項工作，還負責了為了活躍開源活動而進行的開源公開、貢獻、活動等多種工作，因此需要與相關部門合作。因此，我們參考了每個團隊的原始工作和過去的合作經驗，組成了以下的OSRB：

• Open Source Program Office：全權負責所有與開源相關的工作，並在與其他OSRB合作時擔任中心角色
• 法務團隊：支援開源許可證或相關合約的法律審查
• 專利團隊：支援專利許可證相關的審查
• 安全團隊：協助處理開源安全漏洞管理的工作
• CTO辦公室：協助全公司開發組織能夠忠實執行與開源相關的流程
• Developer Relations團隊：協助製作針對內部/外部的開源相關技術內容

雖然我們已經與各部門合作，但將這些內容明確地寫入政策文件並指定實際負責人，這是另一種負擔。幸運的是，所有團隊都同意專案的目標，並樂於指定負責人，並定義所需的責任和能力。

值得一提的是，OpenChain 規範的例子中並未包括 CTO 辦公室 (CTO Office: 譯者，一個跨地區的 LINE 內部最高技術指導團隊，由各公司 CTO 與相關技術部門最高推動者組成) 和 Developer Relations 團隊。在 LINE，我們包括了 CTO 辦公室，以便在問題發生時能與各種開發組織快速溝通，迅速了解情況並作出反應。我們還包括了 Developer Relations 團隊，以便在規劃以開源為主題的各種內容或活動時，能確認開源許可證 (License) 問題，或者增加我們自己的視角，以最大化效果。

制定教育政策

實施開源政策教育並保存評估結果也是 OpenChain 的標準。教育分為針對公司內部開發人員的教育和針對 OSRB 成員的教育。

開發人員教育是針對 LINE 集團的所有開發人員進行的。這是首次對所有開發人員進行的開源必修教育。由於許多人會抽出時間來完成學習，我們深思熟慮了如何組織內容，以及應該強調或省略哪些部分，因此在教育資料中只包含開發人員必須知道的內容。這次教育的最大目標不是掌握所有內容，而是在與開源相關的問題出現時，能記住應該參考哪些文件，應該遵循哪些流程，以及應該向哪裡提問，因此我們專注於這一點來組織教育。

評估也是我們非常擔心的部分。因為沒有人喜歡考試。我們將開發人員常問的問題製作成測驗，以鼓勵他們再次閱讀這些內容，並將我們特別想強調的政策內容設定為較高難度的測驗進行評估。

OpenChain 標準的應用意義

讓我們從公司和開發者的角度來看看應用 OpenChain 標準的意義。

公司角度的 OpenChain 標準應用意義

驗證開源治理結構的國際級優秀性

從企業角度來看，開源合規領域是一個如果出現問題就可能引發大問題，但平時卻不容易確認是否正在良好管理開源，是否可以在合規方面信任的領域。在這種情況下，如果獲得 OpenChain 認證，就可以證明我們正在良好地遵守開源許可證，並且在法律/技術/組織方面不斷努力，並且已經無縫地建立了開源合規體系。通過這種方式，我們可以在與第三方建立合作和夥伴關係時，強調公司的開源管理能力和合規方面，從而獲得信任。

維持內部流程的一致性

OpenChain 標準強調，不僅合規成果，而且產生這些成果的過程也必須有一致的標準。這意味著對特定專案的判斷標準必須明確，並且判斷過程也必須全部定義為流程。例如：

• 原有指南：撰寫開源許可證聲明並傳遞給開發團隊。
• 應用 OpenChain 標準改進後的指南：開源許可證聲明應按照哪種格式撰寫，撰寫過程應遵循以下流程。

OpenChain 標準將這樣的實務過程一一定義為文件，以防止實務人員在相同情況下做出不同的選擇。通過這種方式，無論誰負責開源管理、許可證追蹤、文檔化、教育等內部流程，公司都可以保持一致性，並大幅降低因人為錯誤而產生風險的可能性。

快速且有效的問題應對

根據 OpenChain 標準，我們組建了名為 OSRB 的問題應對協商體，定義了每個成員的責任以及他們將按照哪種流程進行合作。這樣，當風險發生時，我們就有了一個可以快速且有效應對的體系。

開發者角度的 OpenChain 標準應用意義

創造更專注於開發的環境

根據 OpenChain 標準，開發者可以完成開源教育，獲得關於開源的基本知識。接受過教育的開發者可以對基本案例的公司判斷有所預測，或者自己查找和確認文件，如果不能這樣做，他們也會知道可以通過 Open Source Program Office 獲得開源合規相關的幫助。因此，他們可以信任遵循 OpenChain 標準的公司政策，放下對開源相關的擔憂，更專注於開發。

獲得關於開源的基本知識和能力

在進行 OpenChain 專案認證過程中，開發者們直接或間接參與，熟悉公司的開源政策和流程，從而在開發過程中更多地意識到開源許可證並投入開發。如果在開發完成後發現違反開源合規的案例，修正的成本可能會非常高。如果開發者具備開源的基本知識並投入開發，他們可以預先避免開源合規風險，從而更有效地進行開發。