2010 (CC) 葛冬梅, CC BY-NC-ND 2.5 TW.
我國政府每年都會花費大筆的經費在補助科學技術的研究與發展上，許多學校老師、研究機構與私人公司都會申請這類的補助經費來研發軟體，部份計畫的成果甚至後續會進行產學合作，將成果轉換成為實際的商品供社會大眾來利用。而由於自由軟體發展到今日，已經有許多成熟與穩定的版本出現，近年常常可以看到不少的自由軟體元件被利用在政府所補助的計畫當中，一旦這樣的計畫成果走向商業化利用，這些自由軟體元件也將隨著一起成為商業產品被販售出去。
這幾年筆者在工作上常遇到這類性質的問題，詢問這樣的政府補助計畫成果在進行後續商業化的時候，有什麼需要注意之處。因此筆者利用本文簡要地說明重要內容，並建議實際可行的措施。
利用自由軟體來開發的研究計畫，若是預計未來成果將會商業化，首要注意的就是產品中的原始碼是否可以提供給未來的客戶。若是產品的原始碼包含了重要的關鍵技術，一旦外流將會嚴重影響市場競爭力，此時就要避用具有嚴格授權拘束性的授權條款，例如 GPL、AGPL 等授權條款（註一），因為這類條款規定衍生程式也必須採用 GPL 或 AGPL 來授權，因此利用這些條款授權的自由軟體元件，很可能會讓產品中的關鍵技術，嗣後再散布時，也必須採用 GPL 或 AGPL 進行授權，進而導致原始碼與關鍵技術外流的結果。
而若使用的是 BSD、MIT 或是 Apache 2.0 這一類不具嚴格授權拘束性質的自由軟體元件，因為這類條款賦予使用者很大的使用權限，產品中自行編寫的其他程式碼便可以採用不提供原始碼的方式來授權，關鍵技術也就不會因此而外流。例如著名的自由軟體資料庫 MySQL 採用 GPL 授權（註二），但同時也有採用 PostgreSQL License 授權的 PostgreSQL 資料庫可供選擇，PostgreSQL License 是類似 BSD 的授權條款，並不會嚴格拘束衍生程式的授權方式，因此在此例中，對於不想讓產品關鍵技術外流的專案，便可以選擇採用 PostgreSQL 為該專案的資料庫系統，而非 GPL 授權的 MySQL。
其實重點就是，在選擇與利用了自由軟體元件之後，接著在散布上，就必須要遵守個別自由軟體元件的相關義務性規定（註三），若是產品屬性導致無法遵守授權條款中義務性規定的話，那麼就要避用採用這些條款授權的自由軟體元件，改採其他的元件。因此在開發階段，就必須要注意自由軟體元件的授權條款規定，是否符合未來商業化產品的屬性。
此外，筆者強烈建議，在執行計畫的過程中，隨時紀錄利用到的自由軟體相關資訊，包括自由軟體元件原來的名稱、版本號、授權條款全名、條款版本號與下載網址等資訊，然後將這些資訊彙整成為一份自由軟體資訊清單，後續正確運用地這份清單上的相關資訊，將可以降低專案未來商業化時，所可能發生法律糾紛的機率，或者在發生法律糾紛時，也可以幫助減少糾紛可能帶來的損失。
為什麼這樣一份清單可以降低風險或是幫助減少損失呢？筆者在此舉一個反面的例子來為大家說明。
假設執行計畫的團隊甲將成果 F 技術移轉給私人公司乙，F 中有利用到 GPL 授權的元件 S、T，以及 BSD 授權的 U，甲在技術移轉的過程中，並沒有告知乙 F 中包含 S、T 與 U 這三個自由軟體元件，乙日後將 F 修改、包裝成為商業產品在市場上販售，S 的著作權人丙發現這個產品利用到了 S，乙公司卻沒有提供原始碼，因此丙便可能透過律師對乙寄發警告信，要求乙提供產品中 S 與相關衍生程式的原始碼，並且賠償丙為了維護著作權所支出的相關費用。而若乙遭遇到這樣的法律糾紛，可能會歸咎於甲的沒有告知，為此回過頭來向甲請求賠償處理這件法律糾紛所產生的金錢損失。
現在，將以上的例子加以修改：甲在技術移轉的過程，將 S、T 與 U 的相關資訊都完整地告知乙，並且附上一份自由軟體資訊清單作為技術移轉契約的一部份，後來乙將 F 修改、包裝成為商業產品在市場上販售，雖然明知產品中包含有 GPL 授權的自由軟體元件 S 與 T，卻因為衍生程式包含了產品關鍵技術的資訊，所以沒有提供消費者任何取得原始碼的管道，最後如同上例所假設的，乙接到丙的警告信，若乙這時候向甲請求賠償為了處理法律糾紛而產生的金錢損失，甲可以舉出當初提供的自由軟體資訊清單當作證據，證明計畫團隊在技術移轉的過程，已經盡到相當清楚的告知義務，因為如此，甲就可以不需要為乙後續的侵權利用行為來承擔金錢損失。
由上面技術移轉的例子可以知道，對於計畫團隊來說，這份自由軟體資訊清單，確實在實務上可以避免及降低法律糾紛發生的可能性。
而若是遇到計畫團隊未來要自己成立公司，商業化利用該計畫成果的時候，這樣一份自由軟體資訊清單的建立，也可以幫助開發團隊時時注意，所利用到的自由軟體元件是否與未來的產品屬性相符合，若是發現有相衝突的狀況，例如關鍵技術可能會成為 GPL 元件的衍生程式時，都可以依此清單進行分析後即早修改，避免等到商品出貨，在市場上引起法律糾紛時，才來倉皇面對，導致額外的時間成本與金錢賠償。此外，若日後有自由軟體社群詢問該項產品的授權狀態時，這份清單就是最好的紀錄，一來可以節省回頭收集資訊的時間，二來也得以即時回覆以避免產生不必要的誤解。
自由軟體大量被運用的時代已經來臨，成熟、穩定的自由軟體元件在網路上隨手就可以取得，因此當政府補助計畫成果預計要商業化的時候，必須同時考量成果當中利用到自由軟體的可能性，並且規劃相應的開發策略與產品屬性，例如：在保有市場競爭力的前提下，產品中的原始碼是否可以被消費者自由取得？哪些授權條款的自由軟體可以安心利用？哪些授權條款的自由軟體必須禁止利用？若是可以在撰寫計畫申請書之初，就先針對上述問題有了基本的了解，並且蒐集相關的授權資訊，然後加以規劃、納入計畫申請書中，後續並在開發過程中，確實記錄所利用自由軟體元件的狀況，完整地將這些利用狀況與相關資訊彙整成為自由軟體授權資訊清單，並且正確地運用，上述作為，對於計畫成果未來商業化的順利與成功，都將產生莫大的助益。
註一：針對常見的自由軟體授權條款，OpenFoundry 網站有著進一步的中文說明：http://www.openfoundry.org/tw/licenses。
註二：http://www.mysql.com/about/legal/licensing/oem/。補充說明：MySQL 雖然採用 GPL 授權，但同時也提供收取費用的商業授權版本。採用商業授權版本 MySQL 所開發出來的商業產品，其中相關的衍生程式不會受到 GPL 的拘束，也不用因此將原始碼提供給消費者，但卻必須另外支付費用給 Oracle。
註三：關於修改自由軟體的注意事項，請參考 OpenFoundry 上面相關的文章：修改或取用的注意事項，http://www.openfoundry.org/tw/for-developers/1882-2010-07-13-09-53-10；商業產品釋出源碼的實用提醒，http://www.openfoundry.org/tw/for-developers/8127-2010-08-30-15-14-41。