善用管理流程以妥善利用自由开源软体加入产品开发.docVIP

善用管理流程以妥善利用自由開源軟體加入產品開發 經過這二、三十年的發展，自由開源軟體 (Free and Open Source Software, FOSS) 在品質與數量上面均有大幅度的成長，近年來更是大舉被產業界取來進行商業利用，也因此被應用的層面愈來愈廣，但對於傳統上僅熟悉私有軟體 (proprietary software) 授權模式的商業公司而言，初接觸自由開源軟體不免會引發各式各樣的問題與困擾，例如：「是否可以在終端產品中嵌入自由開源軟體進行商業販售？」、「是否作為內部開發工具就沒有延申要提供程式原始碼 (Source Code) 的問題？」、「如何讓工程師快速了解授權內容，從第一線開始避免侵權利用？」。在國內，有些公司已設有專職人員來研究與處理上述的相關問題，不過就筆者所知，這樣的公司目前仍是少數，大部份的狀況是，面臨到自由開源軟體授權問題與困擾的產品工程師，必須肩負起閱讀授權條款、釐清授權義務規定、回覆客戶相關問題，以及研究如何實踐授權義務、讓客戶安心等等的責任，這使得工程師在原本的產品開發與既定的管理工作之外，又增加了研讀艱澀授權條文的工作，而可能導致心力分散、處於不堪負荷的狀態。這樣的現象挑戰著商業公司的管理階層：如何在內部深化應用自由開源軟體的同時，又能夠同步降低可能產生的風險與困擾？因應這樣的轉變與問題，國外許多公司均制定有自由開源軟體產品應用的管理流程，讓員工在利用自由開源軟體元件加速產品開發的同時，有一套制式的流程可以遵循，不過這樣的觀念在國內仍屬少見，因此本文將介紹一個簡化版的自由開源軟體核准流程，作為商業管理流程的範例，藉此向讀者說明善用管理流程所可能發揮的功效。?【自由開源軟體核准流程的運作介紹】 ▲ 圖1 自由開源軟體核准流程圖 這個核准流程圖（註一）由五個問題的自我詢答以構成四種結果，從左邊一排開始，這些問題從上到下依序如下（註二）： 一、自由開源軟體的程式碼將會被保留到終端產品裡嗎？(Will FOSS end up in the final product?) 這個問題關乎自由開源軟體是如何被利用的，若答案為否的話，很有可能這個自由開源軟體只是被當作是產品開發工具，而僅在企業內部使用，如此，原則上就不會有相關的程式碼被散布到組織之外，所以在散布之後才會衍生的種種義務性規定將不會被開啟。但若此題答案為肯定的話，就必須進行第二題的檢測。 二、產品將會被散布到組織之外嗎？(Will the product be distributed outside of the organisation?) 若第一個問題的答案為肯定，表示產品中包含有自由開源軟體的程式碼，第二題問題的重點是，這個包含有自由開源軟體的產品有沒有「被散布出去」，因為若是產品有被散布到組織外的話，就會啟動自由開源軟體授權條款的各種義務性規定，此時散布的組織，就必須要注意散布產品的過程是否遵守授權條款的各項規定，例如散布 GPL-2.0 授權的自由開源軟體的時候，除了將軟體本身的原始碼提供給使用者之外，還必須要提供衍生部份的原始碼才可以，而這樣的義務規定可能與某些產品的販售向性不盡相合 。因此若第二題答案為肯定的話，就必須繼續進行第三題，來檢測這個自由開源軟體是否真的可以用於開發是項產品；而若此題答案為否定的話，這個自由開源軟體便可以被標示為「僅供內部使用 (internal use only)」，因為多數自由開源授權條款的義務性規定，皆不會僅在單純使用軟體時啟動，故確定不會再行散布此一自由開源軟體時，可以先行如此標示，若日後有再散布的需求和可能性，便再就其授權狀態來做細部考量。 三、自由開源軟體是在「核准軟體清單」上嗎？(Is the FOSS on the Approved Software list?) 配合這個核准流程圖，有個由公司主管、產品經理，與法務部門就公司產品販售向性，所預先擬定的「核准軟體清單」，在這個清單上面的自由開源軟體，工程師們便可以安心拿來開發產品，即使產品散布到組織之外，也不會引發與產品販售向性衝突的授權問題。因此若是走到第三題，並且答案為肯定的話，工程師們確定就可以利用這個自由開源軟體來開發產品 (This FOSS may be used for this product)，而不需要花費額外時間研究授權內容與進行個案判斷。 四、自由開源軟體是在「拒絕軟體清單」上嗎？(Is the FOSS on the Rejected Software list?) 若第三題的答案為否定，那麼就還要看看這個自由開源軟體是否被列在「拒絕軟體清單上面」。顧名思義，拒絕軟體清單就是一份工程師們不可以利用軟體的清單，在這份清單上的軟體一旦被利用到終端產品裡，非常有可能與產品販售向性產生衝突，並替組