Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 本網站預計持續維運至 2021年底,網站內容基本上不會再更動。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
Legal Column ASP 與自由/開放源碼軟體的散布條款

ASP 與自由/開放源碼軟體的散布條款

記得從我剛接觸自由/開放源碼授權這個領域沒多久,就人問我這樣的問題:用自由/開放源碼軟體來架設網站,然後向利用網站的客戶收費,卻不提供原始碼這樣算不算違反授權規定?用自由/開放源碼應用程式透過網路向客戶端提供服務,收取費用,卻不提供原始碼,這樣算不算違反授權呢?一直到現在,類似的問題仍然不斷地被提出。在我答覆之後,所獲得的回應常是兩種截然不同的情緒:不是義憤填膺,就是暢然釋懷。

用軟體來架設網站或透過網路向客戶端提供應用程式服務,都是常見的資訊服務形式,也就是業者以 ASP(Application Service Provider,應用程式服務供應商)的身份來營利。ASP 之所產生爭議是因為許多人認為,ASP 用自由/開放源碼軟體來營利,卻不提供修改的原始碼回饋社群,是一種只獲取不付出的行為,因此透過網路提供服務,究竟算不算是自由/開放源碼授權條款中所定義的散布,就成為討論的焦點。若是的話,提供這樣服務的公司就必須向客戶提供程式原始碼,若不是的話,就不需要提供。而現行一般對於散布的定義都並未將「透過網路提供服務」此種運用程式的態樣包括在內,因此,在沒有例外的情況下,對於上述問題,我的回答都是:NO,沒有違反!

這樣的回答讓一些社群朋友義憤填膺,覺得商業公司利用社群開發結晶謀取利潤,卻沒有回饋;同樣回答則讓業界朋友覺得暢然釋懷,因為這樣沒有違反授權規定,也不需要提供原始碼給他人。

這樣的狀況,就我所知,尚沒有解決之道,因為大部分授權條款均採用「散布 (distribute)」這一個詞,而白話來說,目前在法律領域中對這個詞的解釋還停留在,程式是不是真的有移動過,因此在回答這類問題之前我常會問:程式是在哪個電腦上執行的?若是在自己的電腦上執行,那麼就是沒有散布出去;若是在另外一端的使用者電腦上執行的話,那就是有散布出去。

這樣的判斷方式適用於大部分的自由/開放源碼授權條款,當然,GPL 也不例外。不過也有授權條款針對此點有特別規定,AGPL (Affero General Public License v.1)(註一)與HPL (Honest Public License v.1)(註二)即為二例。

AGPL 與 GPL-2.0 基本上是完全相同的內容,只是 AGPL 在第 2 條第 1 項後面多了第 (d) 款,其中規定,若程式執行的方式可以讓使用者透過網路與程式互動,而使用者所接受到的程式版本本身也給與使用者可以要求傳輸完整程式原始碼的機制,此時被授權人在修改程式時,不可將這樣的機制除去,並且也必須提供適當機會,讓使用者一樣可以透過網路與程式互動而要求修改程式的原始碼。

AGPL 這樣規定的立意雖好,但是窺究其內容是以程式本身有讓使用者要求程式碼的機制,若一個程式本身並無這樣的機制,即使適用 AGPL,一樣無法強制要求 ASP 提供其客戶程式原始碼。

HPL 與 AGPL 一樣,以 GPL-2.0 為基礎在第 2 條第 1 項後面增加了第 (d) 款,不過這個增加的內容較 AGPL 來的有力,因為 HPL 直接規定,從解釋使用者取得程式原始碼的角度來看,使用者透過網路與程式互動 (communication) 的型態,也算是包括在散布的認定範圍內。依據 HPL 這樣的規定,ASP 透過網路提供應用程式服務的行為,無論程式是否具有讓使用者要求原始碼的自動機制,也屬於 HPL 所規定的散布,因而必須提供程式的原始碼給客戶。

此外,像 APL (Academic Public License) 與 OSL (Open Software License)(註三)中,特別將「互動 (communication)」與「散布 (distribution)」兩個詞並列,在解釋上也有相當的空間,可以用互動這個概念來涵蓋 ASP 的服務行為,不過筆者至今尚未見到實際運用案例出現。

目前草擬的 GPL-3.0 草案第二版 (GNU General Public License v.3 draft 2),在第 0 條第 2 項定義的 “propagation” 包含了「使公眾可以取得 (making available to the public)」(註四),這樣模糊的文字描述也有著解釋的空間,可以將 ASP 業者行為納入 propagation 中,而產生必須提供原始碼的後續效果。

即使有上述條款的特殊規定,不過筆者至今所看到大部份的 ASP 業者仍不必提供原始碼給客戶,因為這些業者大多採用 GPL-2.0 程式!因此關於這個問題的爭論應該還會持續很常一段時間。未來 GPL-3.0 的內容有可能明確地處理這個爭議,不過這並不代表問題的解決,因為就算有 GPL-3.0 的解決內容,著作權人不採納 GPL-3.0 做為自己程式的授權條款,問題仍然存在。筆者在此只能期待 ASP 業者在可行的範圍內,可以對於開發社群有所回饋,畢竟自由/開放源碼的基本理念是取之於社群、回饋於社群,有取有給如此才能建立一個良好的雙贏環境。
 


註一:AGPL 並非 OSI 所認可通過的授權條款。其原文內容請見這裡。 

註二:HPL 一樣並非是 OSI 所認可通過的授權條款。其原文內容請 見這裡

註三:APL 與 OSL 的介紹請參見:葛冬梅,邱冠勛,OSL 與 AFL:特質完全相反的雙生條款(上),開放鑄造場電子報第62期; 葛冬梅,邱冠勛,OSL 與 AFL:特質完全相反的雙生條款(下) ,開放鑄造場電子報第63期。

註四:可參見該文字的討論




OSSF Newsletter : 第 70 期 Sun 宣佈 Java 將採用 GPL
Tags: ASP,   AGPL,   APL,   HPL,   OSL,  
Category: Legal Column