• 沒有找到結果。

遵守 遵守 遵守 GPLv2 授權條款規定之作法 遵守 授權條款規定之作法 授權條款規定之作法 授權條款規定之作法

第五章 Embedded Linux Embedded Linux Embedded Linux Embedded Linux 的授權範圍 的授權範圍 的授權範圍 的授權範圍

6.1 遵守 遵守 遵守 GPLv2 授權條款規定之作法 遵守 授權條款規定之作法 授權條款規定之作法 授權條款規定之作法

正如自由軟體的愛好者認為傳統的智慧財產權規範方式不恰當,因此在著作權保障 的框架下,提出一套顛覆一般人思維的手段,廠商自然也會在 GPLv2 授權條款的限制下 而發展出因應之道,目前為了避免提供系統程式的原始碼所造成之潛在損失,有些技術 被廠商應用在實務,以下便對這些方式稍作說明。

58

6.1.1 提供程式 提供程式 提供程式 提供程式的原始 的原始 的原始 的原始碼但用科技保護措施規避 碼但用科技保護措施規避 碼但用科技保護措施規避 碼但用科技保護措施規避

科技保措施常是著作權人用來限制他人接觸或利用著作的手段67,無論是美國的數 位千禧年著作權法(Digital Millennium Copyright Act)、我國著作權法關於防盜拷措施的規 定、歐盟的著作權法指令(European Union Copyright Directive),以及世界智慧財產權組織 著作權條約(WIPO Copyright Treaty)等,FSF 都認為這些與 DRM 相關的規定阻礙了軟體自 由。

亦即,DRM 所要保護的權利卻是自由軟體愛好者所希望開放的。過去在制定 GPLv2 授權條款時,並未對這個部分加以規定,導致有廠商利用科技保護措施,對 GPLv2 的授 權條款內容加以規避,因此 GNU 在新版的 GPLv3 授權條款中也對此做出了反制6869。事 實上,關於是否應在 GPLv3 授權條款中定義對 DRM 措施的防止規定引發相當多的爭 議,因為一旦規範後,反而形成對程式使用的限制,進而牴觸四大自由70中的自由 071, 而喪失全面讓軟體可以被自由使用的目的。

利用科技保護措施規避 GPLv2 授權條款的作法中,最著名的就是 Tivo 公司的作法,

也因此,現在類似的作法被稱為 Tivo 化(Tivoization)。Tivo 雖然利用以 GPLv2 作為授 權條款的原始碼搭配該公司的數位影像錄影機(digital video recorder,簡稱為 DVR),也 確實遵守 GPLv2 授權條款的規定,在該公司的網頁提供了原始碼的下載資訊,但該公司 透過在軟體與硬體中設置辨識碼的方式,一旦被授權人對原始碼進行修改並編譯後,新 的原始碼所產生目的碼便帶有一個新的辨識碼,新的辨識碼與硬體預設的辨識碼不一 致,Tivo 的系統程式在發現預設的辨識碼與系統的辨識碼不一致時,便拒絕啟動正常的 功能操作。

易言之,Tivo 的作法是一種對 GPLv2 授權條款採取陽奉陰違的手段,也就是在形式 上遵守 GPLv2 授權條款的規定,配合提供原始碼,但在實際應用時,卻藉由在產品所加 上的判斷機制,以防護的方式判斷被授權人是否使用改動後的原始碼,讓修改過的原始 碼無法發揮效用,因此並未達到 GNU 所預期的,讓原始碼被自由使用而促進交流與進 步的目的。

雖然 Tivo 的行為成為 GNU 等自由派大加撻伐的對象,但是這樣的情形對於以獲利 為目標的商業公司而言,卻是一種相當本能而自然的想法,而且是一個可被預期的規避

67 林靜君,論科技保護措施立法對著作權公共領域之衝擊,逢甲財法所碩士論文,(2008)。

68 Richard Stallman, Why Upgrade to GPLv3, http:// www.gnu.org/licenses/rms-why-gplv3.html (last visited June 5, 2010).

69 參見GPLv3 §6 的規定。

70 The Free Software Definition, http://www.gnu.org/philosophy/free-sw.html (last visited May 22, 2010).

71 “The freedom to run the program, for any purpose.”

59

行為。事實上,這些作法並沒有對錯,只是出於立場或個人想法不同而產生的不同聲音,

一如每個人的道德標準不同,而利用法律確保大家有基本的行為規範,只要大家的行為 確實遵守該些規範,他人也應該予以尊重。

Torvalds 亦曾表示不反對 Tivo 的行為,他認為自由軟體應強調互惠的概念,程式開 發者願意分享自己的原始碼固然值得鼓勵,但別人是否提供原始碼則不應受到原作者的 限制,因此廠商若將自由軟體應用於其他系統時,他也樂見其成。

由於 Torvalds 對於 DRM 的態度較為友善,他也曾公開表明 Linux 作業系統的授權條 款將維持不變,並不會採用對 DRM 有著進一步限制的 GPLv3 授權條款,因此目前使用 Embedded Linux 的嵌入式產品開發廠商,仍可利用 DRM 的方式來維護自身的研發機密。

6.1.2 分開散布 分開散布 分開散布 分開散布

根據 GPLv2 授權條款第二條的規定,如果是與 GPLv2 授權條款的原始碼關聯性不 強的原始碼,廠商可以使用分開散布的方式,減輕提供原始碼的責任72。這個部份還可 以進一步根據實作技術的不同而區分為兩種類型:

6.1.2.1 實體上的分開散布 實體上的分開散布 實體上的分開散布 實體上的分開散布

為了滿足實體尚的分開散布要件,廠商在開發系統程式時,應盡可能對原始碼所提 供的功能加以切割,配合 GPLv2 授權條款的規定,提供被授權人系統程式中,受到著佐 權影響效力而必須提供的原始碼,至於不希望提供之原始碼,則以產生目的碼的方式,

另外提供給消費者。換言之,廠商可以將自行開發的原始碼予以編譯後,提供編譯後的 目的碼在網頁上,讓消費者自行下載,因此結合原有的 GPLv2 授權條款的程式,以及新 增功能的目的碼的過程並不是由廠商自己結合。

如此一來,依照 GPLv2 授權條款的第二條規定,廠商所自行開發功能的原始碼,就 無須提供給下游的消費者,若消費者另外再進行了重製、散布等行為,則提供原始碼的 責任將轉移至消費者。也就是說,消費者必須遵守 GPLv2 授權條款的規定,而提供原始 碼給自己的後手,然而,該名消費者自己並未取得新增功能之原始碼,自然無法依照 GPLv2 授權條款的規定而提供原始碼。因此,廠商若能把自己的核心程式與原本的開放 原始碼區隔,並採用實體的分開散布時,便能避免自己的原始碼受到感染的情形。

72 葛冬梅,GPL 的另類利用方式:「分開散布.責任轉嫁」

http://www.openfoundry.org/component/option,com_content/Itemid,353/id,1711/lang,tw/task,view/ (最後點閱 時間:2010 年 5 月 22 日)。

60

需要注意的是,在分開散布程式時,目的碼的下載與否必須由消費者自行決定,而 不能採用自動化下載的方式,因此應用時,分開散布的對象比較適合在產品的附加功能 上。對產品的主要功能而言,採用分開散布的方式時,產品可能會因為欠缺主要功能而 無法正常運作,再者,由於主要功能彼此的關聯性較高,也無法因為分開散布而得以免 除提供原始碼的責任。此外,這種方式的使用前提是,不同程式的原始碼可以被清楚區 隔,而且下載目的碼的方式與手段不應過於繁複,否則反而可能造成消費者的反感而不 願使用該產品,此為廠商需考慮的部分。

6.1.2.2 動態 動態 動態 動態連結程式與 連結程式與 連結程式與 連結程式與靜態連結程式 靜態連結程式 靜態連結程式 靜態連結程式

簡單來說,使用函式庫的目的是為了簡化程式的操作,而將一些運算或功能透過函 式提供,讓其他程式可以直接使用。當程式與函式庫之間使用靜態連結(static link)時,

代表程式與靜態連結的程式庫間的相依性較高;而程式與函式庫之間使用動態連結

(dynamic link)時,代表程式與動態連結的程式庫之間的相依性較低。針對相依性的不 同,有些論點認為:程式彼此之間的連結方式為動態連結或是靜態連結,可能對一起散 布之認定會不同,進而在判斷是否違反 GPLv2 授權條款時,也會採取不同的認定。

當被授權人所開發的程式使用了以 GPLv2 授權條款進行授權的函式庫時,倘若被授 權人是利用靜態連結的方式使用函式庫,則原始碼在編譯時,函式庫也會被一併被編譯 成為目的碼,這種情況下,由於函式庫與程式原始碼所編譯出的目的碼已經混合而無法 區分,因此屬於 GPLv2 授權條款所規範的「部分」(portion of it)並無疑義。另一方面,

若程式彼此之間係採用動態連結的方式,則因為使用 GPLv2 授權條款的函式庫程式在編 譯時,並不會與使用函式庫的程式一併編譯在一起,因此函式庫的目的碼是在執行系統 程式時,依據執行的狀態,在需要使用相關函式時,才被動態地載入記憶體運作。

為此,有部份人士主張,當系統程式採用動態連結方式來使用以 GPLv2 授權之函式 庫時,應該將函式庫與系統程式視為分開散布73。但此種見解尚未形成定論,亦未經過 相關判決的檢驗,因此其解釋是否成立仍有待觀察。

6.1.2.3 延遲提供 延遲提供 延遲提供 延遲提供原始 原始 原始 原始碼的時點 碼的時點 碼的時點 碼的時點

在開發嵌入式產品時,對原始碼的更動與修改本來就相當頻繁,往往在一個小錯誤

73 ROD DIXON, OPEN SOURCE SOFTWARE LAW 32-34, 2004.

61

發生的時候,便需要對原始碼進行修正,而原始碼尚需要經過編譯、連結產生目的碼後,

將重新產生的目的碼燒錄於嵌入式產品內的非揮發性記憶裝置中,該修改才能算是修改 完成。倘若在數千個程式原始碼(檔案)中,對其中一個檔案的原始碼中的一行,進行 小幅度的修改,便需要將全部的原始碼重新編譯,並提供更新後的原始碼版本,這對於 廠商確實有執行上的難度。

實務上,廠商在提供程式給客戶時,也不會每天提供程式的更新,而係以定期更新 或有重大功能修改時才提供,因為程式的更新也可能衍生其他問題,因此在經過一段時 間之測試後才提供之程式也具有相對較佳之穩定性,因此程式原始碼的即時更新除了有 實現的困難外,也非最好的提供手段。由於 GPLv2 授權條款並未限定提供原始碼的時 點,因此廠商可以利用原始碼的更新,與提供實際提供原始碼時點之時間差,避免將最 新的原始碼提供出來,讓提供原始碼所造成的負面影響得以降低。

由Skype 的訴訟也可以發現,參與自由軟體開發的社群之所以會提出訴訟,其目的 是迫使廠商配合提供原始碼,因此廠商若表達配合的舉動與意願時,社群會根據廠商的 態度而決定是否繼續進行訴訟。因此就原始碼的提供時點來說,除非是因為已經被社群 盯上,基本上,廠商只要在社群可以容忍的期限內,依照 GPLv2 授權條款的規定,配合 提供系統程式的原始碼即可消除社群的敵對態度。

由Skype 的訴訟也可以發現,參與自由軟體開發的社群之所以會提出訴訟,其目的 是迫使廠商配合提供原始碼,因此廠商若表達配合的舉動與意願時,社群會根據廠商的 態度而決定是否繼續進行訴訟。因此就原始碼的提供時點來說,除非是因為已經被社群 盯上,基本上,廠商只要在社群可以容忍的期限內,依照 GPLv2 授權條款的規定,配合 提供系統程式的原始碼即可消除社群的敵對態度。

相關文件