莊薇馨 律師[1]
採用開放原始碼軟體已成為全球企業IT部門的常態
開放原始碼軟體性質上為電腦程式之一種，其仍為著作權法規範之著作，並受著作權法保障，其散布亦必須受授權契約條款之限制，開放原始碼軟體與一般商業軟體最主要之不同處在於其授權契約條款內容。一般商業軟體之授權契約條款主要係以收取權利金作為授權之對價，而開放原始碼軟體之授權契約條款，則主要是授權人應維持其開放原始碼軟體程式的自由性與開放性為對價，開放原始碼授權契約之主要特色為：散布時應公開軟體原始碼、應促使開放原始碼軟體得自由被其他使用者下載、使用、複製、修改，並得以任何目的自由地散布予第三人[2][3]。
有鑑於網路的蓬勃發展與應用，越來越多人得藉由網路協作工具，參與開放原始碼軟體的開發與編輯，也因為開放原始碼軟體是由多數人共同參與開發，開放原始碼軟體優化、創新之速度有時甚至較一般企業自行研發之商業軟體迅速，近幾年來，越來越多的軟體公司如Apple、Microsoft，為節省自身開發成本、促使自身之產品得為更廣泛之運用也都紛紛將自己底層技術之原始碼開源。依據Sonatype發布之2020年軟體供應鏈現況報告顯示，2020年內世界各地的開發者已提起超過1.5萬億個開放原始碼軟體組件和軟體單元的下載要求，顯見開放原始碼軟體當前之高使用率。
常見之開放原始碼軟體授權契約類型
目前實務上有諸多種類之開放原始碼軟體授權契約，依「保障程式修改版本自由程度」（亦有稱「Copyleft」效力）為區分標準，目前常見之開放原始碼軟體授權契約得粗淺分類如下。
| Copyleft 效力 |
最強 | 折衷 | 最弱 |
| 契約類別及特性 | 保障原始碼及修改後的軟體版本仍是開放原始碼軟體之授權契約 | 折衷型授權契約，確保專有軟體開發者和開源軟體開發者間之平衡 | 准許被授權人具有自由利用該軟體的權利之授權契約 |
| 範例 |
|
|
|
GPL類型授權契約
GPL類型之授權契約，相較於多數開放原始碼軟體授權契約而言，具有最強之Copyleft效力，此類型授權契約最重要之精神為「適用GPL契約的軟體，其修改版本或衍生著作也必須適用同樣的GPL授權契約條款散布或授權出去」。以目前GPL類型之授權契約中較多數人使用之GPL v.2為例，GPL v.2授權契約共有12條條款，其中，較重要的條款如第零條規定，GPL授權契約保護之標的包含著作權人通知得依該GPL授權契約條款散布之任何電腦程式或其他著作（所謂「本程式」即指該種電腦程式或其他著作），以及「基於本程式所生之著作」，即指本程式或其他著作權法規定之衍生著作。另依據GPL v.2授權契約第二條規定[4]，如果被授權人欲修改本程式，必須符合三項要件：(一)被授權人須令修改後檔案上明顯註記該檔案已遭修改及修改日期；(二)被授權人針對其擬散布之包含全部或部分本程式或本程式所衍生之著作，須依GPL授權條款完整無償授權予第三人；(三)如果修改的程式通常在執行時以互動方式讀取命令，被授權人應使其在開始進入一般互動使用時列印或顯示聲明，包括適當的著作權通知及無擔保聲明（或被授權人提供擔保聲明），且使用者可按此條件散布該程式，並告知使用者如何檢視此授權影本（例外：如本程式本身以互動方式工作，但通常不列印上述聲明時，被授權人基於本程式的著作也不用列印聲明）。但單純聚集散布行為得除外不受上述散布之限制。
依據上述條款，即便僅係「基於原程式所生之著作」未來授權時亦須同樣採取GPL v.2授權契約，且依據GPL v.2授權契約第二條，此授權不得收取費用。
另GPL v.2第三條則係在保障被授權人可以以目的碼或可執行型式散布其著作，但必須同意無條件提供公眾接近原始碼的機會。其他條款內容包括：需聲明原著作權人、標示不負擔保責任等。倘被授權人違反了GPL授權條款，則其因該授權契約所享有之所有權利將會終止，授權人可以要求違反之被授權人禁止繼續散布、修改原程式及其衍生著作。
MPL授權契約
MPL授權契約係網景公司在1988年，將其Netscape網路瀏覽器原始碼公開時所採用之授權契約[5]，相較於GPL類型而言其Copyleft效力稍弱，MPL授權契約與GPL類型最大不同處即在於「若被授權人並未對MPL授權契約所授權之軟體進行任何修改，則被授權人可以任何授權條件將該軟體或結合的軟體散布出去。」換言之，在被授權人對原軟體未有任何修改且以使用原授權契約之前提下，被授權人對MPL授權之軟體有新的著作權，被授權人可以使用其他授權契約再授權出去[6]。
BSD授權契約
BSD （Berkeley Software Distribution License）授權契約則源於加州大學柏克萊分校，為目前實務上使用最廣泛之授權契約，BSD授權契約僅要求被授權人散布時僅需聲明原著作權人、標示不負擔保責任及不得利用原授權人名義對改作後的衍生軟體背書或進行推廣，除此之外被授權人無其他義務。BSD授權契約並未如同GPL類型之授權契約要求衍生之著作，須以同樣之授權條款散布，也未要求不得收取費用。
企業採用開放原始碼軟體應注意之法律問題及對策
隨著開放原始碼軟體使用率之提升，相關法律風險亦隨之而來
近年來，工程師利用開放原始碼軟體進行再創作、企業搭配使用開放原始碼軟體及自行研發之軟體提供產品、服務，已蔚為趨勢，隨著開放原始碼軟體使用率之提升，相關法律風險亦隨之而來。基於開放原始碼軟體自由散布之本質，任何人應得以十分輕易的取得開放原始碼軟體（且大多係無償取得），並進而對取得之軟體原始碼進行修改，惟開放原始碼軟體並非公共財（Public Domain），其著作權人仍舊對開放原始碼軟體享有著作權，並受著作權相關法規之保障，故使用者僅有在遵守授權契約條款之前提下，始享有任意修改、散布開放原始碼軟體之權利。
目前國外已有數法院著有相關案例承認開放原始碼授權契約之效力，舉例而言，在2006年，台灣友訊 （D-Link）的德國子公司因其販售NAS 產品的驅動程式中，採用了GPL 授權契約授權之軟體，但因D-Link並沒有依據GPL授權條款規定附上無擔保聲明，也沒有提供使用者驅動程式原始碼以及 GPL 授權條款全文，而為著作權人Welte提告，最後D-link敗訴，且需收回其已販售之產品。
建議企業在使用開源軟件之前進行一定的盡職調查，儘早制定內部使用開源軟件的政策，並對內部員工進行定期培訓和教育
由於開放原始碼軟體在開發之過程中可能融入了許多人的貢獻，如果任一貢獻者不當將他人之軟體專利、或其他專屬軟體，使用於開放原始碼軟體中，則可能導致整個開放原始碼軟體涉入智慧財產權侵權訴訟中[7]。除前述著侵權之風險外，企業使用他人研發之開放原始碼軟體尚可能涉及感染病毒、內部機密程式可能須採用特定授權條款而被迫公開等風險。
以上述案例為鑑，企業在使用開放原始碼軟體應事先就個別開放原始碼軟體所採用之授權契約進行審查，包括一併評估企業擬創作之衍生著作是否可能包含機密程式碼、有無須將GPL授權之原始碼和非GPL授權之原始碼分開散布之策略等，以確保企業在散布開放原始碼軟體符合相關授權契約條款，不致構成侵權。企業如事先知悉相關開放原始碼軟體涉及他人智慧財產權時，應先取得權利人同意或另找尋其他替代方案，但倘企業難以確知擬採用之開放原始碼軟體是否可能涉及他人權利，而又無可避免地須使用該開放原始碼軟體時，則或可考慮藉由保險機制以適度分散風險。
實務上，目前有企業使用開源軟體前，將採取事前自行驗證之方式，於採購軟體時，要求其下游廠商提供「產品包含的開源程式碼」以審視每個供應鏈環節是否都已履行開源義務，惟企業採此自行驗證程序可能需耗費一定之時間、金錢成本；另外，亦有企業透過向符合特定第三方標準（如：OpenChain[8]）的企業取得開源程式碼，以確保所使用之程式碼已經過嚴格的法令遵循程序。
最後，建議相關業者尚應盡早訂定內部使用開放原始碼軟體之政策，並定期對內部員工進行相關教育訓練，使員工熟知公司使用開放原始碼之政策、程序、違反開放原始碼授權之後果等，提前評估及控制使用開放原始碼軟體之風險，始能避免企業因內部工程師不當使用開放原始碼軟體使公司造成不可回復之損害、真正享受開放原始碼軟體帶來之價值。
[1] 作者為理慈國際科技法律事務所執業律師，惟本文內容為個人意見，不代表事務所立場。
[2] St. Laurent, Andrew M. (2008). Understanding Open Source and Free Software Licensing. O’Reilly Media. p. 4. ISBN 9780596553951.援引自Wikipedia, 網址: https://en.wikipedia.org/wiki/Open-source_software，最後瀏覽日期: 2020年11月16日。
[3] 程式設計師Bruce Perens於1998年成立加州的非營利組織Open source initiative專注於保護和發揚開源軟體、開發和社群，並創造了開放原始碼軟體之定義。依據Open source initiative官方網站介紹，開放原始碼軟體之散布條件需遵守以下十項標準：1.重新發佈自由（Free Distribution）；2.開放原始碼（Source Code）；3.可衍生寫作（Derived Works）；4.需可保障原著作人原始碼之完整性（Integrity of The Author’s Source Code）；5.不可歧視任何個人或團體（No Discrimination Against Persons or Groups）；6.不可歧視任何目的或領域（No Discrimination Against Fields of Endeavor）
7.需要散佈授權許可（Distribution of License）；8.其中授權條款不得專屬部份特定產品（License Must Not Be Specific to a Product）；9.授權條款不得限制其他軟體（License Must Not Restrict Other Software）；10.授權條款須保持技術中立（License Must Be Technology-Neutral）。
[4] Open Source Initiative, GNU General Public License version 2, 資料來源: https://opensource.org/licenses/GPL-2.0，最後瀏覽日期: 2020年11月16日。
[5] Announcements – Updating the MPL. Mozilla Foundation. 資料來源:https://web.archive.org/web/20120313153018/https://mpl.mozilla.org/announcements/，最後瀏覽日期: 2020年11月16日。
[6] 參楊智傑、李憲隆，開放原始碼授權契約之法律與策略分析，智慧財產權月刊第58期，民國92年10月。
[7] 張憶嬋，開放原始碼軟體商業模式及相關法律問題之探討，民國95年6月，第156頁。
[8] OpenChain官方網站連結:https://www.openchainproject.org/，最後瀏覽日期: 2020年12月7日。