善用管理流程以妥善利用自由開源軟體加入產品開發

經過這二、三十年的發展,自由開源軟體 (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?)

若第三題的答案為否定,那麼就還要看看這個自由開源軟體是否被列在「拒絕軟體清單上面」。顧名思義,拒絕軟體清單就是一份工程師們不可以利用軟體的清單,在這份清單上的軟體一旦被利用到終端產品裡,非常有可能與產品販售向性產生衝突,並替組織帶來法律糾紛。因此若是軟體在拒絕軟體清單之列,工程師們就不可以將這個軟體用於開發是項產品 (This FOSS may NOT be used for this product)。

這邊值得注意的是,若是軟體既不在核准清單之列,也不在拒絕清單之列,那麼這個流程圖所導出的答案是:「請與法務部門聯繫取得核可!(Please contact the legal department to obtain approval)」這代表當一個自由開源軟體既不在核准清單、也不在拒絕清單,是該組織法務部門之前所沒有瀏覽過的授權方式,這個軟體的授權規定可能與產品販售向性不符,若是貿然利用,可能會引起法律糾紛,所以必須要由經由法務部門進行個案式的瀏覽與研究,確認沒有問題之後,工程師才可以將這個軟體應用到產品中。

五、透過自由開源軟體處理,而產生的額外程式碼將會被保留到終端產品裡嗎?(Will code generated by the FOSS end up in the final product?)

第五個問題其實是承接第一個問題而來。當第一個問題的答案為否定,一個自由開源軟體本身的程式碼不會被保留在產品裡,此時、並不完全代表利用這個軟體,便確定沒有授權義務性方面的問題,因為有些被當作開發工具的自由開源軟體,在執行過程中,可能會將已身一部份的程式碼植入至該開發程式裡,例如 GCC (GNU Compiler Collection) 在編譯的過程中,便會自動植入部份的程式碼至編譯成果裡,就解釋上來說、伴有其程式碼的編譯成果也有機會被認定為 GCC 的衍生程式,而必須一體適用 GPL 來向外授權,不過針對此點、GCC project 已清楚表示這種狀況適用其特別律定的 Runtime Library Exception(註三),使用者在編譯行為上,可以例外的不受到 GPL 授權條款的拘束,然而、並非所有的編譯或其他的自由開源軟體開發工具,都設有這樣的例外規定。所以、若是透過自由開源軟體處理,會產生額外的程式碼被保留到終端產品裡的話,此時這個被植入程式碼的產品專案,一樣必須要通過第二題以下的核准流程,工程師才可以利用這個自由開源軟體來開發產品。相反地,若是這個自由開源軟體並不會在產品中置入額外的程式碼,顯示這個軟體是單純的工具程式,那麼工程師便可以安心利用它來開發產品,而毋須擔心衍生授權義務性方面的爭議。

【適當的規劃導入將帶來長期的整體效益】

以上的核准流程圖僅為一個簡單的範例,以這份流程為基本架構,還可以有許多的調整變化,例如:若公司已經有專案開發的版本控制系統 (version control system),便可將這個流程圖加以系統化,融入成為版本控制系統的部份功能,讓工程師在開發產品的同時,直接透過系統平台的驗證程序,來檢查是否可以使用所欲取用的自由開源軟體;又或者可以延伸流程圖上第三題的內容,讓工程師在利用自由開源軟體開發產品的同時,知曉有哪些聲明必須一同置入到產品中,以符合自由開源軟體授權規定的要求。諸如此類的調整或內容延伸,可以視公司與產品販售向性的不同,而有許多的變化,來讓產業界商業化運用自由開源軟體時,能夠以更為便利而有效率的方式來進行。

不過行文至此,筆者並不諱言,國內多數公司現階段在規劃與導入這樣一套管理流程上有其難度,因為要建置管理流程基礎的第一步,便是得了解自由開源軟體授權條款的相關內容,才可以規劃出適合公司產品販售向性的軟體清單、核准流程,或者是其他延伸的管理程序,不同販售向性的產品也可能無法共用同一份清單與流程,這些了解與規劃的過程都必須投入相當的人力與時間。然而!若是應用自由開源軟體來開發公司產品,已經是一個不能完全避免的選項,那麼制定適當的流程,以便利工程師與聘僱員工來認識並利用自由開源軟體,則將是一條不可避免的道路,因為這樣的流程不但可以省卻工程師身兼法務的窘境,進一步透過了解、規劃的過程,將可以強化公司成員對於自由開源軟體的正確認知,有助於活用自由開源軟體,同時降低未來所可能衍生的法律風險。因此從整體來看,投入一定期間進行適當規劃以導入管理流程,將會對產業界在自由開源軟體的長期利用上,帶來整體的效益與幫助。

Acknowledgement: With thanks to Royal Philips Electronics, Shane Coughlan and other anonymous contributors for making efforts to release the chart under Creative Commons license to the public.


註一:這個核准流程圖的出處:Shane Coughlan, presentation slide "Licensing Compliance as Business Intelligence", 2010/05/11, p. 18, licensed under CC-BY-ND 3.0 Unported License, available at: https://www.openfoundry.org/slides-download/cat_view/35---/330-2010/356-0511。此核准流程圖原為荷蘭飛利浦公司 (Royal Philips Electronics) 內部管理自由開源軟體流程的一部份,經調整簡化後成為現在這個版本的基礎。自由軟體鑄造場於 2010 年邀請歐洲自由軟體基金會 (Free Software Foundation Europe, FSFE) 資深顧問 Shane Coughlan 來台演講,Coughlan 先生略為調整流程圖中的用語後,用在演講簡報中,並且採用「創用CC-姓名標示-禁止改作 3.0 未本地化版本」授權條款釋出此圖,也就是本文所採用的這個版本。感謝荷蘭飛利浦公司、Shane Coughlan 以及調整本流程圖以利釋出的貢獻者!

註二:Shane Coughlan 先生原核准流程圖中的英文採用「Free Software」一詞,不過由於本文的中文用詞統一採用「自由開源軟體 (Free and Open Source Software, FOSS)」,因此在解說流程圖的部份,改以「FOSS」一詞來置換原圖之「Free Software」,特此說明。

註三:進一步的說明資訊,可參照 GNU Project 對 GCC Runtime Library Exception 的正式說明頁面:https://www.gnu.org/licenses/gcc-exception.html

 




自由軟體鑄造場電子報 : 第 190 期 開放源碼的安全演算法工具︰OpenSSL(1) - 基礎操作與雜湊演算法
標籤: Open Source,   OSS Policy,   商業化,  
分類: 法律專欄