【開源社群建言：中華民國軟體自由協會理事長楊宇凡】不只是用程式碼，政府擁抱開源還能做的2件事

企業擁抱開源稀鬆平常，但政府要藉開源之力實踐國家級IT計畫，就是一件大事。

衛福部資訊處主導的次世代數位醫療平臺計畫就是一例，他們鎖定全臺醫院，要全面導入國際醫療資料交換標準HL7 FHIR、臨床品質語言HL7 CQL等國際標準，並透過制定符合臺灣醫療情境的FHIR本地化規範（TW Core IG）、發布以CQL編寫的健保申報規則庫來實現。

這項計畫還提出3大差異化策略，針對醫學中心要開發一套一條龍工具，來協助轉換FHIR、臨床醫學術語標準SNOMED CT、實驗室檢驗檢查編碼LOINC和藥品編碼RxNorm等國際標準，對區域／地區醫院則要打造一套數位底盤（PAUL），來升級醫院IT系統，對衛生所則要客製化開源電子病歷系統OpenEMR，將其在地化為適合臺灣醫療流程的公版黑熊醫療資訊系統（HIS）。

不論是FHIR、CQL還是OpenEMR，都得借助開源專案來執行，也仰賴公私協作。但最近，這個過程出現了爭議，承接衛福部該計畫的工研院，其生醫所工程師在計畫官網上公開的健保申報CQL規則原始碼，是以美國政府AHRQ開源專案程式碼來修改、開發，連同README說明檔都支字未提授權聲明，遭開源社群工程師質疑。而後，該工研院工程師還在TW Core IG中新增一段補充條款，明確禁止該社群工程師及其公司使用或散布TW Core IG，引發各界熱議。（相關報導詳見：工研院出面道歉！承包衛福部次世代數位醫療平臺計畫，引發2大開源授權爭議）

隨後，工研院與衛福部相繼發聲明、承諾補正授權內容並解除特定個人封鎖，衛福部也在第一時間通知美國AHRQ，還將成立由外部專家組成的事件調查委員會來釐清問題、進行後續懲處，但仍衍生出政府擁抱開源的管理問題。對此，iThome專訪中華民國軟體自由協會理事長楊宇凡，來談談開源社群角度的觀察與建議。

認同政府擁抱開源，但也需尊重前人貢獻

中華民國軟體自由協會（簡稱軟自協）成立24年多，長年推動自由軟體、軟體自由，也就是提倡使用開源軟體，且人人都有選擇軟體的自由。

他們承辦過教育部校園自由軟體數位資源推廣服務中心（OSSACC），將自由軟體及開源數位教材帶進校園，也於2015年聯手國發會，推動開放文件格式ODF，作為政府文件標準格式之一。

2017年，當歐洲自由軟體基金會發起「公共出資，公共程式」（Public Money, Public Code）倡議，提倡政府開發的公共程式要自由開源授權、允許重複利用、避免廠商壟斷，且民眾參與協作時，軟自協立即響應，是第一個連署的非歐洲組織，並在臺推動PMPC。到了2017、18年，他們也將FHIR這項公開標準納入推廣範圍，來協助民間和政府採用。

因此，對於衛福部次世代數位醫療計畫大規模擁抱開源和開放標準，「協會是高度肯定的。」楊宇凡指出，政府力擁國際標準，臺灣的人才和技術，才有辦法與世界接軌、輸出到國際。只不過，協會提醒，使用開源專案或標準，也得尊重其開源精神，尤其是開源社群前人的貢獻。

舉例來說，政府可以表明授權聲明，來表彰原作者，或建立回流貢獻機制來改善原始專案，比如修復Bug、新增功能等。又或是更進一步，投入維運資源來協助原始專案優化、永續經營，「協會期待政府不只是使用開源，也可以將對開源的態度，提升到更高層次。」他說。

爭議事件凸顯的3個不足

進一步細看這次爭議，楊宇凡除了再次肯定政策方向，也點出政府擁抱開源的3個不足。

首先是對開源軟體管理的不足。以符合PMPC的歐美國家為例，其政府在委外打造公共出資軟體時，會要求委外單位先盤點現有軟體、衡量是否已有類似的開源專案，好來客製化開發、延續開源精神，若無，則另外開發；而後的開源軟體採購、合規審查、回饋等一系列流程，也會納入標案合約中。就這次衛福部計畫來說，目前仍停留在「使用開源軟體」，而「沒有充分的系統性盤點、合規審查與後續回饋等完整的開源軟體管理流程。」

另一個不足是缺乏統籌單位，來進行開源軟體的授權、審查、管控與協調。尤其，公部門與執行單位的法務、資訊開發和採購等各職類缺乏有效溝通、各自為政，甚至在風險產生時，未能及時察覺，引發公共信任危機。

第三個不足是缺乏統一諮詢的管道。楊宇凡表示，此事件顯示該工研院工程師，缺乏使用開源軟體的正確知識和訓練，比如不知何時需要標示授權、正確引用開源專案，事發時也沒有統一的諮詢管道，提供該工程師、衛福部或承包單位相關資訊。

建議1：成立開源專案辦公室

也因此，軟自協依PMPC原則，提出內控和外稽2大建議。就內控來說，衛福部可參考國外做法，成立開源專案辦公室（OSPO），來提供合規性驗證、單一諮詢窗口和跨單位協調，甚至是教育訓練與社群互動。

楊宇凡解釋，因現行標案驗收只驗功能、不驗授權（License）等內容，而OSPO可以早期介入開源專案的合規性驗證，避免事後補破網。再來，OSPO也能作為政府單位和承商的單一諮詢管道，提供具體建議，比如工程師開發遇到問題，可求助OSPO。此外，OSPO能跨政府局處和承商，來互相協調，讓政府在監督標案的過程中更加順利，而非作為嚴厲批判的監督者。

甚至，OSPO也能作為與社群雙向對話的窗口，比如政府提出專案想與民間合作，OSPO可擔任溝通窗口，民間也能透過OSPO來反應專案問題，如程式錯誤等。OSPO還能提供教育訓練，來強化機關內部與承商的開源意識，或進一步將開源受訓納入標案資格或履約條件，就像是將常見的基本法規講習概念，延伸到開源標案中，來審核廠商開源能力。

OSPO不是新概念，以歐盟為例，早在2020年就已成立跨局處的OSPO專責小組，至今還整合了600多套工具。楊宇凡認為，OSPO能成為政府行政自我約束的實踐，以昭公信，對未來推動公私協力開源專案，非常有說服力。未來，不同的OSPO之間，還能共享資源，分享各自的專案程式、準則、政策等，實現資源再利用。

建議2：開源專案與程式碼

就外稽而言，軟自協建議，政府機關開發的軟體、平臺，若能開源、受公眾監督，「從根本上開放民主參與，就能讓政府的平臺變得更好。」楊宇凡解釋，此次爭議是很好的契機，不論黑熊版HIS、TW Core IG還是一條龍工具，未來若開源供大眾參與，社群、業者就能貢獻其力來改善品質，讓工具變得更好用，「會是一個很好的起點。」

更進一步，協會認為，政府可參照PMPC精神，接軌歐美國家公部門開源專案做法，將開源要求寫進標案規格中。以義大利數位局（AGID）為例，他們負責推動政府數位轉型與創新，早年就發布指引，規定政府專案及程式碼必須開源，而且還提出重複使用索引（Reuse index），列出開源成果供各政府單位重複使用、不必重新造輪子，還能節省經費支出；就連負責數位基礎建設的德國內政部（BMI）也提出類似政策，來要求政府專案開源。

至於何時該開源，「越早越好。」楊宇凡解釋，從風控角度來看，最好在開發初期就能開源供公眾檢視，才能避免開發單位使用他人成品或半成品改裝交差等情況。

「政府機關未必有能力馬上識別問題或驗收，甚至可能開發下去，才發現承包商開發能量不足而爛尾。」他表示，這些風險可透過早期開源、公共參與來避免，政府也能進一步以開源貢獻經驗，作為選擇標案廠商的參考，或是要求廠商執行標案前，先進行開源PoC概念驗證專案來檢視。

跟上國際PMPC腳步

這2項內控與外稽建議，都以PMPC為核心。放眼國際，不少組織和國家都遵照PMPC原則，成立專責單位、設置公共程式平臺來推動公部門開源專案，除了歐盟OSPO、義大利AGID、德國BMI，法國數位部DINUM也建置一套公共程式平臺，來提供政府開源專案程式碼，供公眾檢視。甚至美國還有負責推動政府開源政策的單位18F，提供指引來規範開源內容。

「歐美國家已用這樣的高度看待開源，臺灣在醫療上接軌國際的同時，是否也要跟進國際開源做法？」楊宇凡提問。

其實在臺灣，數發部已根據PMPC精神，建置一套公共程式平臺，目前也有不少中央和地方政府在平臺上公開程式碼，比如數發部網站防竄改偵測系統、環境部電子公文封裝檔附件名稱解析、臺南市登革熱防疫現場數位工具前臺、臺南市災害影響評估平臺、臺北市政府城市通架構與服務等。楊宇凡建議，未來，衛福部可將次世代數位醫療平臺計畫的開源專案程式碼，上載到公共程式平臺。

 更多相關報導