close
讓人既愛又頭痛的 GNU/GPL Print E-mail
Written by 葛冬梅    Friday, 27 May 2005

GNU Genral Public License(以下簡稱GNU/GPL)是第一份自由軟體授權條款,也是目前最廣為被使用的授權條款之一。自由軟體之父 Richard M. Stallman(以下稱 Stallman)為了替他的軟體開發計畫 -GNU 計畫尋找適當的授權方式,在 1989 年草擬出 GNU/GPL 第一 版。它的整個架構與理念源自於Stallman所宣示的軟體使用者四大自 由(註一):

【自由0】使用的自由:可以不受任何限制使用該軟體。
【自由1】研究的自由:可以研究該軟體的運作方式,並使其符合個人需求。
【自由2】散布的自由:可以自由地複製該軟體並散布給他人。
【自由3】改良的自由:可以自行改良該軟體並散布改良後的版本,以嘉惠眾人。

為了實現上述研究自由與改良自由,使用者必須可以取得軟體原始 碼。而任何一個符合上述四大自由的軟體就可以被稱為自由軟體。 為了落實四大自由,Stallman 設計了一套不同於當時既有的著作權 授權模式-copyleft。這套制度最大的特色有二:

   1. 使用者可以免授權金地執行、重製與散布該程式,並且同樣免授 權金地取得程式原始碼;
   2. 任何基於程式原始版本所開發出來的修正版本(modificaiton) 仍然必須使用相同的授權條款﹔

透過這樣一套機制,不僅僅最初的原始程式版本是免授權金、開放原始碼,就連之後所產生出來的修改版本也一樣。所需要注意的是,這一切的基礎是奠基在著作權制度之上,所以自由軟體仍然是有著作權的軟體。 Copyleft 制度落實為具有授權條款文字就成為了 GNU/GPL。它的主 要內容包括:

   1. 使用者在散布程式重製物的時候(例如:燒成光碟給他人),必須 附上原始碼。使用者也可以用目的碼(object code)的形式散布程 式,但是必須讓收到目的碼的人知道如何取得原始碼。
   2. 使用者在散布程式時,仍必須適用 GNU/GPL,無論所散布的是原始版本或是修改版本。
   3. 不收取費用。除了以不收取授權金的方式讓使用者自由執行、重製、 修改與散布程式之外,原則上 GNU/GPL 軟體也不收取任何費用,不 過使用者可以在散布程式重製物時,為了支付重製或散布的成本,又 或者是為了自行提供擔保而收取費用。
   4. 不附隨擔保(warranty)。因為不收取任何費用,所以 GNU/GPL 原則上不對使用者提供任何擔保,不過如上所述,使用者可以自行提 供擔保。

GNU/GPL 因為基於 copyleft 所發展出來,再加上條款當中規定, 對於就算是僅僅擷取一小段原始碼來使用,因此而開發出來的程式也必須要透過 GNU/GPL 來授權,所以有人稱 GNU/GPL 像是病毒一般 (viral license),會將其他的程式原始碼也感染成為開放狀態。這種病毒的感染特性,雖然維持了 Stallman 對於自由軟體自由開 放的理念,卻剝奪了一些使用者對於軟體授權條款內容的選擇權利,所以 GNU/GPL 是集毀譽於一身的授權條款。 這樣的特性對於認同自由軟體理念的程式開發者以及單純的程式使用者來說,是相當受到歡迎的,但是對於那些想要使用 GNU/GPL 程式原始碼,卻不願意將所開發程式原始碼公開出來的人來說,卻是相當頭痛的,因為他們必須割愛去另外尋找合適的替代程式。此外,還有一些人使用了 GNU/GPL 程式原始碼,卻不清楚其中的規定,之後才知道必須開放原始碼,卻礙於一些理由無法將原始碼公開,這種情況在承接政府計畫開發軟體時,就有可能發生,因為依 據相關規定,接受政府經費補助所開發出來的軟體,原則上必須在我國境內使用,雖然有例外規定可依循,但是礙於既有行政作業程序的僵化與繁複,依據例外規定 並非易事。 GNU/GPL 目前最新的版本為第二版,其中當然有許多適用上的問題,因此由 Stallman 所創辦的自由軟體基金會(註二)正在著手草擬第三版,期待修改出來的版本更為完善。不過上述 GNU/GPL 令人既愛又頭痛的特性,應該還是會繼續被保留,因為就是這些特性使得自由軟體得以廣泛地流通,並且受到越來越多人的認同與支持。

 

註一:有關GNU計畫的緣起與GPL產生背景請參見:http://www.gnu.org/。
註二:自由軟體基金會(Free Software Foundation,FSF):http://www.fsf.org/。

究竟包含多少的GPL程式碼才算……? Print E-mail
Written by 葛冬梅    Friday, 24 March 2006
對於 GPL(註一)有所了解的人都知道,一旦一個程式包含 GPL 程 式碼,所開發出來的程式也必須要採用 GPL。GPL 第 0 條第 1 段中 相關的原文是這樣寫的:“... that is to say, a work containing ... or a portion of it, ...”。這樣的規範內容相當模糊,究竟包 含多少 GPL 程式碼行數才可以算是這裡的“portion of it”?若無行數上限標準,這樣的規定又顯得過於嚴苛。因此各方對於這一段文 字的詮釋總是眾說紛云。 依照 GPL 草擬者 Richard Stallman 所表示的最嚴格標準,即使是 一行 GPL 程式碼,也構成“portion of it”。這樣嚴格的解釋為許 多人所無法接受。

不過因為 GPL 這一項規定內容尚未接受過法院程序的檢驗,因此到如今也只能眾說紛云,重點就回歸到程式著作權人身上。目前著作權 制度賦與著作權人很大的權限,除非在授權中有寫明,否則著作權人 他可以隨時收回原有的著作權授權內容,改換另外一套完全不同的授權內容,因此無論大家如何詮釋「包含 GPL 程式碼」的意涵,只要 著作權人念頭一轉,就可以將原有的著作權授權內容改變,直接寫明 為「即使包含一行的GPL程式碼」。

這樣聽起來真是沒有安全感,還好這種事尚未發生在現實生活當中。

不過不安全感依然存在,因此有人開始在技術上做各種規避的嘗試。 其中引起熱烈討論就是,動態連結 GPL 程式碼的方式是否構成 GPL 的“portion of it”。

若是採取靜態連結 (static link) GPL 程式碼,因為在編譯時 GPL 程式碼會被直接一起編譯為目的碼,因此這種情況下所開發出來的程 式,許多人認為是構成 GPL 的“portion of it”。若是採取動態連 結 (dynamic link) GPL 程式碼的方式,因為 GPL 程式碼在編譯時不會被一併編譯入目的碼,而是在執行時才被載入記憶體中運作,因 此有人認為採用這種方式所開發出來的程式不構成 GPL 所規定的 “portion of it”,在沒有其他限制內容的前提下,程式著作權人 可以自由制定程式授權內容(註二)

而除了靜態、動態連結的區分標準外,就筆者所知,針對 GPL 的 “portion of it”尚未有其他類似或具體的區分標準,因此對於這 項議題有所認識的程式開發者,不是避用GPL程式碼,就是一旦採用 就一定依照 GPL 的遊戲規則來授權所開發出來的程式。

目前 Stallman 所提出的第三版 GPL,對於引起這樣爭論的文字並未 有所修改,因此在可預見的未來,相同的問題、爭論以及不安全感還是會繼續下去。

註一:有關GPL介紹,請參見:葛冬梅,讓人既愛又頭痛的 GNU/GPL ,自由軟體鑄造場電子報第33期
註二:有關於動態連結的討論可參見此

 

GPL的另類利用方式:「分開散布.責任轉嫁」 Print E-mail
Written by 葛冬梅    Saturday, 30 August 2008
一個常被提出的問題:要如何在利用 GPL 程式碼的同時,避免其他部份的程式碼也被 GPL 感染?之前曾經提過一些抽象的判斷標準,例如採用動態連結(dynamic link)利用 GPL 程式碼,因此開發出來的新程式,許多開發者認為可以不用受到GPL的拘束,但是採用靜態連結(static link)利用 GPL 程式碼,許多開發者認為新程式仍應該採用 GPL 授權。這樣的標準仍是相當抽象,這期的法律園地就來談一個比較具體的方式,筆者稱這樣的方式為「分開散布.責任轉嫁」。 所謂「分開散布」是指將 GPL 程式碼與非 GPL 程式碼分開散布,「責任轉嫁」則是將提供原始碼的責任轉嫁到他人身上。聽來這好像是兩件不同的事情,要怎麼樣才能兜在一起呢?現在就說個甲跟乙的故事來說 明。

甲 開發一個程式,裡面利用到 GPL 程式碼,這個程式也因此採用 GPL 授權,甲將這個程式燒在光碟裡送給朋友乙。甲另外還為這個程式寫了一些附加元件,這些附加元件完全是甲自己寫的,並沒有利用到 GPL 程式碼,甲決定只讓他人可以安裝、執行這些附加元件,但是並不提供原始碼給別人。甲把這些附加元件放在網路上,當乙將程式安裝到電腦上的時候,安裝過程中 跳出一個視窗,裡面有一些說明文字,並且詢問乙是否要下載放在網路的附加元件並安裝,乙選擇「是」,這時候,電腦將附加元件下載並安裝到程式裡。乙用了這 個程式,覺得這些附加元件很棒,來跟甲索取原始碼。

甲:「我還不想提供附加元件的原始碼。」
乙:「可是你這個程式不是 GPL 授權的嗎?這上面的附加元件也應該是 GPL 授權的,依照 GPL 規定我就可以跟你拿到原始碼啊!」
甲:「程式是 GPL 授權的沒錯,但是附加元件並不是 GPL 授權的,所以不受到 GPL 的拘束。目前我只想給人用而已,並不想把這些附加元件原始碼給人。」
乙指責甲:「怎麼會這樣?你這樣違反了 GPL!」
甲:「我並沒有違反啊!這些附加元件完全是我自己寫的,根本沒有用到任何 GPL 的程式碼。」
乙:「但是這些附加元件是跟程式結合在一起,是一起執行的啊!」
甲 說:「我並沒有把附加元件程式碼與 GPL 程式碼結合在一起,『結合』這個動作是『你』做的,程式安裝過程不是有問你「是否下載並安裝附加元件」,此外還有說明文字,說明這些附加元件並非 GPL 授權的,並不提供原始碼給人,若是你同意將附加元件安裝到程式,會讓安裝在程式上的附加元件也成為 GPL 授權,在沒有附加元件原始碼的狀況下,你將無法依照 GPL 規定來散布這整個程式。這些說明都你瞭解並同意,才會按下『同意』按鈕。所以讓附加元件感染成為 GPL 授權的人是『你』,不是我」
乙:「我...沒注意看清楚那些說明文字......」

甲在這裡用的方式,就是將程式與附加元件分開散布,讓結合的動作由乙去完成,是乙讓附加元件受到 GPL 感染,身為附加元件完整著作權人的甲,因此還是可以隨心所欲地來決定要給他人原始碼或是不給。

那 麼,「提供附加元件原始碼」的 GPL 責任落在誰身上呢?這就要看是誰散布「結合有附加元件的程式」了!在這個故事中,甲不會這麼做,就只剩下乙了。若乙真的將「結合有附加元件的程式」再給他 的朋友丙,丙來跟乙索取附加元件原始碼的時候,乙就沒有合理的理由可以拒絕,因為這整個「結合有附加元件的程式」都是 GPL 授權的!大家可能會覺得這樣對乙並不公平,因為乙根本沒有原始碼,只有甲擁有原始碼,可甲偏偏又不提供出來。是的,這這樣的方式對於乙來說似乎不夠公平, 但是這樣的利用與散布方式,並沒有違反 GPL 的遊戲規則!乙因為沒有注意到當時畫面的說明文字,而直接下載安裝附加元件,這個時候所能做的,就是「不要散布」這個結合有附加元件的程式,因為提供原始 碼責任的產生,導因於散布 GPL 程式,只要沒有散布行為,就不會有後續的提供原始碼責任了。

以上故事中的「分開」手法,並不侷限於「光碟-網路」,也可以是「裝置(device)-網路」,或者是任何其他合乎這樣遊戲規則的方式。而再加上附加元件真的沒有用到 GPL 程式碼,這時候,責任就轉嫁到他人身上了!

這就是「分開散布.責任轉嫁」的方式,而這種方式的類似應用並不少,讀者稍微留心觀察一下,可能就會在自己使用的自由軟體中發現如故事中的「附加元件」。

「分 開散布.責任轉嫁」這樣的方式雖然沒有違反 GPL 文字規定上所表達出來的遊戲規則,但筆者也不敢肯定地說,這樣的利用方式完全沒有爭議,因為目前並沒有確定的法院判例可以當作參考標準,所以就容易因為理 念不同而產生不同的立場。對於堅持徹底貫徹 GPL 精神的人來說,可能並不贊同這樣的利用方式,但是對於其他人來說,這卻是一種十分合理的解釋與利用方式。而當堅持徹底貫徹 GPL 精神者,不贊同的情緒升高到一定程度時,很可能我們就會在 GPL 第四版中看到與之相關的規定,如同第三版對於 TiVo 與 DRM 有相關規定的情況一樣。

筆者個人對此並沒有特定的立場,只是希望透過本文來說明,除了一般所認知的「完全不用 GPL 程式碼」外,還有這樣一種另類的利用方式,此外,也希望大家在透過這種方式利用 GPL 程式碼的同時,可以加強相關說明文字的呈現方式,讓使用者可以清楚明瞭這個下載安裝行為所帶來的後果,並自行決定是否願意承擔這樣的後果。


● 本文的完成特別感謝林誠夏以及鑄造場同仁所提供的意見。
● 延伸閱讀:葛冬梅,究竟包含多少的 GPL 程式碼才算…?,自由軟體鑄造場電子報,第 54 期

 

 

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 kezeodsnx 的頭像
    kezeodsnx

    心的距離

    kezeodsnx 發表在 痞客邦 留言(0) 人氣()