Comment are off

如何避免違反自由軟體授權規範

「為何我必須考量本公司是否遵守自由軟體授權合約?」

過去,這個問題主要發生在電腦軟體公司或其他科技產業。然而,隨者自由軟體(Open Source)快速的發展,今日不論何種產業,所有與軟體使用或軟體開發相關業者,均需詢問自己相同的問題。多數業者針對第三者授權的商業軟體(Proprietary Software)均有認知,且瞭解遵循商業軟體授權合約的重要性。業者藉由採購程序,針對第三人授權商用軟體進行相關查核,並審閱軟體授權合約。此外,亦針對相關授權合約是否確實履行,建立內部控制機制。然而,相較於商用軟體,僅有少數業者對於瞭解其企業是否使用自由軟體,並瞭解遵守自由軟體授權合約的重要性及違反的後果。多數業者並未針對自由軟體設立制度以確認公司內部是否使用自由軟體或是否遵守相關授權規定。此種現象,導致許多公司處於違反自由軟體授權合約的高度風險及伴隨的相關責任。鑑於此種潛在的危險,每一個使用軟體或開發軟體的公司均應瞭解為遵守自由軟體授權規範的風險,並採取行動避免危險產生。

本文提供適當機制,供企業瞭解並減少不當履行自由軟體授權合約的風險。 作者 Jason D. HaislmaierTPPT    譯者 顧慕堯TPPT

1. 背景介紹

1-1. 自由軟體的法律本質

自由軟體在不同的角度上有不同的定義。自由軟體可以是一種協助軟體開發或維護的有力工具。TPPT 或者,自由軟體制度被認為是原始碼(source code)普及性及商用電腦軟體的理想制度。TPPT 而自法律觀點,自由軟體乃基於自由軟體授權合約所授權使用的軟體。自由軟體不同於商用軟體,亦不同於免費軟體(Freeware)或已成為公共財產(Public Domain)的軟體。與免費軟體及公共財產軟體相較,自由軟體透過授權合約課予軟體被授權人特定契約義務。TPPT 因此,自由軟體不應該被誤解為「免除」相關法律義務。然而,自由軟體授權合約課予法律義務,與傳統商用軟體授權所伴隨的義務有顯著的區別。通常,傳統商用軟體合約對終端使用者(end user)就軟體的使用多作限制,尤其對於軟體的原始碼。相反的,自由軟體授權制度則提供較為「開放」的法律架構,其特徵在於原始碼及二位元碼(binary code)可取得性、修改軟體得權利及散佈修改軟體的權利。

「自由軟體定義」(Open Source Definition)針對自由軟體的「開放」法律架構設有界限。TPPT 「自由軟體定義」為Open Source Initiative(OSI)組織所頒佈。TPPT OSI組織就符合「自由軟體定義」的軟體授權合約進行認證(OSI Certified)。一旦經由OSI組織認證,此類合約多被認定為自由軟體授權合約。「自由軟體定義」訂有許多標準,使特定軟體授權合約具備自由軟體的性質。TPPT 「自由軟體定義」主要標準如下:

  • 原始碼可取得性(Source code availability):軟體授權契約必須授與原始碼(人類可判讀)及目的碼(機器可判讀)二種型式的軟體。倘若授權軟體僅以目的碼格式提供,授權人必須提供授權人以合理重製費用取得原始碼及目的碼的管道。同時,原始碼必須處於軟體工程師得進行修改之態樣。
  • 自由散佈:如授權軟體與其他軟體結合,授權契約不得禁止被授權人就該結合之軟體授權第三人;授權契約亦不得收取權利金或其他使用軟體之對價。
  • 衍生著作:授權契約必須允許被授權人修改授權軟體及創作衍生著作,並且允許修改後的軟體或衍生著作,以原軟體授權合約相同合約條款進行散佈。

「自由軟體定義」的功能與產業就特定技術或產品以一定標準制訂之規格相似,以相同的標準使後續的應用均符合規格並具相容性。「自由軟體定義」規範的標準具一定的寬度,允許許多類型的授權合約得被歸納為自由軟體。實際上,本文撰寫時,有近六十種自由軟體合約業經OSI組織一句「自由軟體定義」認證。TPPT 其中著名的授權合約有「通用公共許可證」(General Public License; GPL), 「次通用公共許可證」(Lesser General Public License; LGPL), MIT, BSD及APACHE。除此之外,許多授權合約標榜其為自由軟體,實則未經OSI組織認證。部分未經認證的自由軟體合約是本於一個或數個經OSI認證自由軟體授權合約內容,其部分合約條款符合「自由軟體定義」;然而,另有部分條款與「自由軟體定義」的要求具有顯著的差異。

鑑於OSI認證之自由軟體授權合約的多樣性,各類自由軟體於授權時,因實際採用不同的軟體授權合約,其授權內容的差異性更為加劇。雖然詳細比較各類自由軟體授權合約的差異並非本文所包括,試以copyleft型態之授權合約及非copyleft型態之授權合約為例,簡單說明。TPPT Copyleft型態之授權合約被認為具有所謂的「毒性」(viral effect; 譯按:viral effect並非指copyleft型態之授權合約有害,而是指該種型態之授權合約對其衍生著作散佈及原始碼可取得性的強大效果),例如GPL及LGPL等合約。此類合約條款要求被授權人就衍生軟體開放原始碼,使公眾有取得機會。TPPT 而非copyleft型態之授權合約,例如BSD及MIT合約,則不包含該等效力的合約條款,而通常僅於被授權人對外散佈授權軟體時,要求被授權人需表明權利歸屬及著作權標示。TPPT 基於前述自由軟體授權的多樣性,任何人不應誤以為各類自由軟體授權合約的內容均大同小異,實則,應該在使用自由軟體前,仔細瞭解自由軟體的授權內容。

1-2.何人應重視自由軟體授權是否切實遵循?

企業如有使用第三人開發的軟體,正逐漸瞭解該公司無法完全避免使用到自由軟體。即便企業決定禁止使用自由軟體,他們通常發現公司內部或公司產品仍有使用自由軟體。例如:

軟體開發者在主管不知情的情況下,使用自由軟體於開發計畫中。

經併購取得的軟體技術業已使用自由軟體。

公司內所使用外部開發的軟體,可能含有自由軟體。

國內或國外的軟體開發者或受委託開發軟體者,可能於企業委託的軟體開發計畫使用自由軟體。

於此種自由軟體極有可能被使用的情況下 ,企業無可避免的應妥適瞭解企業內部及其產品使用自由軟體可能帶來的風險,並採取對應措施。

自由軟體授權生效方式與傳統授權不同,自由軟體授權並不以當事人簽名或類似的表示為契約生效要件。實際上,自由軟體授權合約約定軟體使用者一旦使用或散佈自由軟體時,即發生授權法律效果。TPPT 亦因此,支持自由軟體的論述者認為自由軟體合約乃授權人業提出要約(具要約拘束性),當被授權人為承諾時,授權合約即生效力TPPT。許多此類論述者業已大量討論GPL及其他自由軟體合約執行力的法律分析。TPPT 雖然本文不討論該等法律分析,但值得重視的是該等分析結論漸漸肯認自由軟體授權的執行力。

支持自由軟體授權合約執行力的美國及外國法院判決日漸增加。於美國,透過法院判決解釋自由軟體授權合約執行力的腳步相當緩慢。本文撰寫之時,僅有少量訴訟案件於美國法院討論GPL及其他自由軟體授權合約的執行力。TPPT 而該等訴訟案件多以和解收場或與合約執行力無涉的法律基礎判決。目前,僅有一件訴訟案件間接肯定GPL合約執行力之有效性。TPPT 然而,在歐洲至少有二起事件,法院認定GPL合約有效TPPT。 目前,部分團體聲稱全球現有三十件以上訴訟案件,訴請企業違反自由軟體授權合約。TPPT 除法院訴訟外,部分私人團體,例如自由軟體基金會(Free Software Foundation)及gpl-violations.org,更透過各種方式積極的執行GPL授權合約。TPPT 目前的處理方法主要是與違反GPL授權者進行非公開談判為主,據該等團體表示協商結果多屬成功。TPPT 鑑於多數法律論點認為自由軟體授權合約具備執行力、各國法院對該等法律見解支持度之提昇,以及執行自由軟體授權合約日益增加的成功實例,企業不應再以自由軟體授權合約不具備執行力而輕忽,而應該慎重考量違反自由軟體授權合約的效果。如前所述,各類型的自由軟體授權合約中多樣化的合約條款課予自由軟體被授權人不同的義務。當特定自由軟體被使用時,該自由軟體授權合約內容即課予被授權人合約義務。因此,目前尚無分析方式得有效的分析各種自由軟體授權合約的內容,亦無分析方法得分析特定的自由軟體授權合約是否足以適用所有情況。然而,於具體個案仔細分析特定自由軟體授權合約條款及其事實背景仍有其必要性。顯而易見的,倘若未同時對自由軟體授權合約及使用自由軟體之事實背景有所瞭解,將無從分析該軟體授權合約之適用性。自由軟體使用者若沒有前述認知,將使自身陷於違反自由軟體授權合約的高度危險中。如同其他契約效力,違反自由軟體授權合約可能導致嚴重後果。例如,部分軟體授權合約,包括GPL授權合約,約定違反該授權合約時,該授權立即終止。TPPT 目前該等終止條款被法院認定具執行力,因此GPL授權合約之被授權人一旦違反GPL授權合約,被授權人無權主張授權人應先為終止通知或被授權人應有補正機會,而被授權人將面臨授權合約立即終止的可能性。TPPT GPL授權合約終止後,將導致原本的被授權人無權使用GPL的自由軟體,若原被授權人繼續使用該軟體,將導致著作權侵害。

於商用軟體授權合約違約時,以法院禁制令禁止該軟體的散佈為常見利器。如前所述,歐洲法院針對軟體散佈行為違反自由軟體授權合約者,准予發給禁制令。TPPT而美國法院在何種情形下,始會針對違反GPL或其他自由軟體授權合約的指摘發予禁制令,尚不清楚。然而可預見的未來,美國法院將以傳統上以禁制令停止軟體散佈侵害商用軟體行為之方法,針對軟體散佈違反自由軟體授權合約之行為,採取相似的處理方式。

除了違反自由軟體授權合約的後果外,漠視自由軟體的使用亦將導致其他風險,例如:

  • 合約解釋爭議:目前自由軟體授權合約不但種類繁多,許多契約條款更是規範不清楚或含糊不清。儘管為公眾所接受的契約解釋業已開始發展,然而自由軟體授權人與被授權人間,就授權合約產生解釋疑義的可能性依舊相當高,並導致後續的爭議。
  • 權利內容不確定:自由軟體的開發模式乃一種集體的製作方式,透過個別開發者的貢獻所集合而成之軟體開發專案。TPPT 通常,自由軟體開發過程中,並未針對個別開發者之貢獻有無侵害他人智慧財產權,以法律觀點進行充分的判斷。TPPT 自由軟體被授權人自此種集體開發方式所取得的權利,不會大於軟體開發者因軟體創作所產生的權利。倘若自由軟體開發過程中,某一軟體開發者對其開發的軟體並不享有充分權利時,即表示任何該自由軟體的被授權人亦無法就該具有瑕疵的軟體享有充分的權利。目前投入自由軟體開發的參與者日益增多,亦表示軟體開發者對其開發軟體欠缺完整權利的機會同步增加
  • 欠缺瑕疵擔保所導致風險:大多數商用軟體授權合約提供一定程度之瑕疵擔保,聲明軟體之適用性及智慧財產權侵害等事宜。許多商用軟體授權合約更針對前揭聲明提供違約保證。然而,多數自由軟體授權合約並不提供瑕疵擔保及違約保證。自由軟體授權合約因欠缺瑕疵擔保及違約保證,使得自由軟體之被授權人面對自由軟體權利有瑕疵或侵害他人智慧財產權時,無法如同商用軟體被授權人享有原權利人的協助。

1-3. 應如何遵守自由軟體授權合約?

使用自由軟體所伴隨的風險通常較為複雜。企業導入有效率的自由軟體遵循制度得令企業內使用自由軟體的能見度增高,並降低風險。但是,一體適用的遵循制度並不存在。過度公式化或依據一般性質檢查表的遵循制度,通常無法就企業面對特定風險予以對症下藥。而過於仔細的遵循制度通常於既有資源下無法實施且永遠無法完成。唯有透過企業切實瞭解公司內部使用特定自由軟體的本質及複雜程度、決定何種遵循程度適用於公司及界定各種遵循制度,企業始能建立適合的遵循制度。雖然此一任務不簡單,目前企業實務執行自由軟體遵循制度已有些許成功典範。依據既有經驗,前揭成功典範乃源自於企業以量身打造方式,制訂其自由軟體遵循制度。本文下一段將依據成功典範提供建立實施自由軟體遵循制度相關訊息。

2. 建構自由軟體遵循制度的步驟:

2-1. 建立自由軟體風險預測指數(Risk Profile)

每一個公司針對自由軟體伴隨之風險有不同的容忍程度。因商業模式及商業模式潛在風險,不同企業有不同的風險容忍程度。於決定是否使用自由軟體前,企業應先評估自由軟體伴隨的風險及公司的風險容忍程度,進而建立自由軟體風險預測指數。評估時除考量一般人於使用自由軟體面臨之風險外,同時需考量企業因其商業模式之不同,所面臨之特殊風險。同時,需考量公司商業模式內主要領域,諸如:公司主要軟體產品或商業領域現有或未來之獲利。考量因素或有:軟體授權是否占公司直接或間接收益之大部分?亦或是,公司主要收益是來自於硬體銷售或硬體相關服務及維護?公司是否持續維護相當數量的專利?目前維護的專利是否與軟體有關?公司是否有任何收益係源於該等軟體專利授權?公司建立風險預測指數時,應確保公司所選擇的評估因素,真實的反映公司商業模式及風險容忍程度。公司評估時,針對與高風險相關的因素,應賦予相當的加權,反之,對於低風險的因子,則無庸花費過多心力。企業應利用自由軟體風險預測指數來衡量其使用自由軟體可能帶來的利益及競爭優勢。透過此衡量機制,許多公司發現在一定方式下,該公司願意使用自由軟體。通常,這些公司同時會發現,使用自由軟體的態樣會影響公司對於使用自由軟體的接受程度。例如:某公司可能願意接受數種類的自由軟體授權合約。但在考量特定情況的風險後,該公司可能僅願意接受某一特定的自由軟體授權合約。透過評估程序,針對營業模式中對於自由軟體風險容忍程度較低的主要核心專案或營業領域,該公司可能會設定特定的自由軟體使用規範,並就不同風險忍受程度的領域適用不同的規範。企業通常先選擇風險較高的領域(通常風險忍受度較低)進行自由軟體遵循制度,嗣後再將該遵循制度導入其他領域。在部分情形,企業經評估後發現使用自由軟體所伴隨的風險過高,且無法為公司的風險預測指數所接受。在此情形,該企業或許應採行其他方案作為合理對應決定,例如:授權取得商用軟體或自行開發商用軟體,以替代自由軟體。

2-2. 執行自由軟體查核工作(Open Source Audits)

唯有透過真正瞭解自由軟體何時及何種方式被使用,始得緩和自由軟體所伴隨的風險。而執行自由軟體查核工作始能完全瞭解自由軟體的使用現況。執行自由軟體遵循制度前,自由軟體查核工作得令企業勾勒出公司內既有自由軟體的使用現況。公司導入自由軟體遵循制度後,針對上市前新產品或即將履行之商業交易進行自由軟體查核工作,企業得確認先後自由軟體授權規範的一致性。其他時點之查核工作(甚或抽查)得確認自由軟體遵循制度及政策是否確實貫徹。無論如何,查核工作應於產品上市前或交易完結前提早安排,以避免因不良查核結果導致產品上市或交易的延誤。

查核程序應按不同企業、不同商業模式及使用自由軟體的程度及性質而設計。無論查核程序如何設計,查核程序的首要目標在於確定公司內使用自由軟體的性質及情形。通常,查核程序至少包括自由軟體的名稱、該自由軟體使用的授權合約種類、自由軟體授權人為何人或何組織,及公司使用該自由軟體的方式。TPPT 舉例而言,自由軟體是供企業內部使用,或是隨同產品或服務而對外散佈?該自由軟體係按照原本情況使用或是業經修改?該自由軟體是否與本公司開發或授權取得之商用軟體相互連結或以其他方式互為影響?若相互連結或影響,該連結或影響的本質為何?以上僅為舉例,其他資訊或許亦很重要,企業萬勿以本文所提供查核表或其他查核表即為以足。許多公司發現透過對IT或研發單位同仁進行問卷、意見調查或面詢,可以有效的蒐集前述訊息。此外,企業亦應向外部軟體授權公司詢問授權產品有無使用自由軟體。目前市面上可購得自動化工具,用以檢視企業內部使用的軟體碼並得掃瞄有無自由軟體之軟體碼存於企業內部。通常,這些自動化工具是將掃瞄所得之企業內軟體碼與已知的自由軟體資料庫進行比對。雖然這些自動化工具對自由軟體查核工作有相當的幫助,但企業不應該完全倚賴該自動化工具進行查核工作,自動化工具至多僅得作為自由軟體規範的一部份。

2-3. 制訂自由軟體遵循政策

成功的自由軟體遵循制度都需要一個內容一貫且有條理的政策為其核心。該政策應描述企業內自由軟體存在的情況。例如:軟體開發人員使用自由軟體、對外購買的軟體含有自由軟體或因企業併購等交易之標的含有自由軟體。自由軟體遵循政策也可能說明其他使用自由軟體的情形,例如:公司基於自由軟體授權約定,對外揭露公司軟體,進而成為自由軟體社會的一員、員工貢獻於自由軟體專案或公司透過研究開發計畫,資助自由軟體專案。根據公司的商業模式,其他公司使用自由軟體的情形可資借鏡,此外,政策制訂時應保留彈性,盡量歸納與公司相關的使用情形於政策中。

(1)自由軟體審查及核准程序:當企業決定使用自由軟體,企業應該針對自由軟體使用的需求,建立內部的審查核准程序。此程序主要目的在使公司知悉每一個所使用的自由軟體且按授權方式使用。當有意使用自由軟體的軟體工程師提出需求時,審查程序啟動。若能於審查程序規定,審查需求之提出應於專案完成前或資料揭露前進行,則屬更佳。如此一來,得使審查程序進行即時的評析,且得避免囿於需求所致偏差性的分析。再者,若使用自由軟體的需求遭審查程序否定且須另覓替代方案時,亦能減少軟體開發過程中或商業交易中可能的延誤。

(2)使用自由軟體之需求必須於該 (to be continue…)

關於正誠