本篇分享十多年來選用自由/開放源碼軟體(或第三方軟體)的經驗，主要是從四個面向來分析：技術、社群、法律及精神。

Image

一般人多從「技術」、「社群」及「精神」角度探討，但鮮少探討「法律」的風險。

1. 技術

文件充足，文件是否齊全？文件內容是否正確？文件是否隨著軟體版本更新？

程式優美，程式碼是否排版整齊？格式正確？富含測試碼？函式/變數名稱清楚明瞭(或註釋完備)？

更新穩速，程式是否仍持續更新？更新是否穩定還是時常踩地雷？更新流程是否簡便？需額外補充的是，有些發展長久、變化不大的領域，未必需要時常更新，例如加解密演算法。

2. 社群

參與人數，程式核心開發者人數及其實力？使用者人數？專案平台上的得分數 (如 GitHub 上的按讚數)？

活躍程度，待辦追蹤系統是否持續有人討論？程式臭蟲解決的速度？程式開發者更新專案的頻率？網路上有許多人共同討論 (如 Stackoverflow)？

商業支援，除了社群支援外，是否有完善的商業公司支援？商業公司是否足夠穩健？支援實力是否滿足需求？

3. 法律

授權條件，程式授權的契約條件是什麼？貢獻程式碼時需要放棄什麼權利？使用程式時需要付出什麼義務？這些權利與義務是否違背公司宗旨？

適用產業，程式授權條款是否合適於本產業？例如，App 開發者通常建議不要使用 GPL 類的程式授權；雲端產業通常建議不要使用 AGPL 類的程式授權等。

相容分析，程式授權的權利與義務是否與公司專案的其它相關軟體間有法律衝突？例如，GPL-2.0 契約版本與 GPL-3.0 契約版本不相容、LGPL-2.1 契約版本與 GPL-3.0 契約版本不相容、BSD-4-Clause 契約版本與 GPL-2.0 契約版本不相容，其它還有很多。通常若法律狀態不相容，則不得把這些軟體放在同一個專案/產品中。

4. 精神

開源宗旨，是否同意程式核心成員對於「開源」的解釋？每個人對於「開源」的解釋未必相同。

開放程度，程式是否全部開源？還是只是核心開源但 plugin 不是(亦或相反)？是否和善地接納外部開發者的程式或文件貢獻(有些非常難以接納)？接納外部貢獻時，是否需要額外簽署權利移轉(放棄)契約？例如，Ansible 曾被社群批評過不夠開放，而 MariaDB 的授權法律框架與過去 Oracle MySQL 幾乎無異，我個人認為也是假開放。

商業羊皮，是否只是假借開源之名，行商業之實？例如，Sencha 公司雖然釋出非常多開源專案，但其態度及法律解讀，完全都是以商業角度看待，與一般認知的開源解釋差異太多，容易產生彼此的誤會。