很高興有這樣的地方可以討論法律相關的授權議題...

我想請教兩個問題：

1. 在閱讀版上相關的文章，發現有提到：

GPL程式的授權承繼性/感染性原則上會在三種情況下開啟，一是修改感染、二是取用感染、三是結合感染(link、merge、combine)

我想請教的是，若使用的是 Perl / Python / Ruby 這類的動態語言，在專案中有使用了 GPL 的程式，也會受到結合感染的影響？還是說這條限制需要有"編譯"的行為才會有影響？

2. 若我們使用了動態語言開發了一個系統，而之後隨硬體整機出貨至客戶端。由於我們販賣的是機器所提供的服務，所以不給機器的帳號權限讓客戶使用，這樣客戶是否有權利要求我們釋出原始碼？

謝謝解答疑惑

Hi williewu,

抱歉拖了很久才有時間來進行討論，

以下簡短回答你的問題。

1、使用 Perl / Python / Ruby 這類動態語言，在專案中使用了 GPL 的程式，也會受到結合感染的影響？還是說這條限制需要有"編譯"的行為才會有影響？

這個問題我們可以切成三個子題來討論，第一個子題是「程式語言本身有沒有著作權」，第二個子題是「使用 Perl / Python / Ruby 程式語言所編寫的軟體，在執行時會用到這些程式語言的直譯器，那會不會讓自行編寫的軟體被迫成為自由軟體」，第三個子題是「若在專案中使用了GPL授權的程式，會不會讓整個軟體專案都受到GPL授權條款的拘束」。

A、程式語言本身有沒有著作權?

我個人認為沒有程式語言本身不受著作權法的保護，這在法律論理上或許有爭議，但從著作權法的保護目的來說，演算法、數學方法、技術或機器的設計均不屬著作權所要保障的對象，而程式語言類比上近似演算法及數學方法，一般來說是不會受到著作權法所保護的。

B、使用 Perl / Python / Ruby 程式語言所編寫的軟體，在執行時會用到這些程式語言的直譯器，那會不會讓自行編寫的軟體被迫成為自由軟體?

不盡然，它可以是、也可以不是。以 Perl / Python / Ruby 寫出來的程式在執行上需要各該語言的直譯器(Interpreter)，這些直譯器確實都是程式著作，但它們的授權方式都不具有影響其它程式授權狀態的「感染拘束性」：

* Perl：https://dev.perl.org/licenses/
* Python：https://www.python.org/download/releases/2.4.2/license/
* Ruby：https://www.ruby-lang.org/en/LICENSE.txt

所以單純使用這些直譯器都不會影響到你自行編寫軟體的授權狀態，除非你去「改寫」這些直譯器本身，那改寫出來的版本就可能要再依各該條款來授權。

C、若在專案中使用了GPL授權的程式，會不會讓整個軟體專案都受到GPL授權條款的拘束?

這屬於GPL結合感染的討論(Link, merge, combine)，依GPL2.0的規定，除非你個別撰寫的程式能主張獨立性(independent and separate)，否則再散布時就要受到GPL授權條款的拘束，獨立性來講一般來說有三個條件：1、個別程式裡未直接抄寫GPL授權的程式碼；2、除去此一連結的GPL程式，整個軟體專案仍然可以維持基本功能的運作，一般來說就是動態連結的方式，而不能用靜態連結的方式來取用這個GPL授權程式；3、不要將整個軟體專案結合成一個可執行程式直接散布。

2. 若使用動態語言進行系統開發，而後隨硬體整機出貨至客戶端。但是所販賣的是機器提供的服務，所以客戶並沒有使用機器的帳號和權限，這樣的商業模式，客戶是否有權利要求得到機器的程式原始碼？

因為狀況描述的有點模糊，所以我還是把這個題目設想為三個狀況的子題來進行討論，第一個狀況是「所販售的是像TiVo一般的嵌入式硬體裝置」，第二個狀況是「出租的印表機，客戶只得到使用權」，第三個狀況是「運出服務的提款機，機器的所有權從來沒有移轉過」。

其實就GPL2及3的規定來說，必需涉及程式碼的移轉(Convey)，那麼散布GPL程式者才有提供給後手程式原始碼的義務，所以基本上只要程式碼沒有散布，那持有GPL程式者就沒有提供程式碼的義務會產生。

A、嵌入式的硬體裝置，它的程式原始碼還是有移轉，雖然一般使用者並沒有改寫它的能力，但是若買受人是power user就可能有這個能力，關於這類的嵌入式裝置在GPL3裡著墨甚多，結論就是還是要提供程式原始碼，這包括嵌入式韌體的安裝資訊及編譯腳本。

B、出租的印表機裡面有內嵌GPL的程式碼，但機器只是出租並未所有權予客戶，那麼此時內嵌於印表機裡的程式碼算是轉移了嗎?這真的是一個蠻有趣的好問題，我想以自由軟體基金會的看法還是會認為此時程式碼已經轉移了，畢竟若是這樣就可以規避GPL的拘束性的話，那麼Richard Stallman應該會氣的急跺腳，說不定會在GPL4明文禁止這種行為；並且其實GPL討論的標的原則上是著作權，和所有權和租賃權未必正相關，我個人的看法是這個狀況程式碼還是移轉的，畢竟客戶能夠使用這台印表機，就法律用語上客戶「持有」並且完整的支配了這台印表機上程式碼的運作，與Google透過網路來服務客戶，程式碼從未移轉到客戶電腦的ASP方式不同(Application Service Providing)，但當然、這是我個人的看法，就法律論理上，這裡確實是會有爭議的空間。

C、例如銀行將內嵌有GPL程式碼的提款機置於便利商店，或是電玩業者將投幣式的遊戲機置放於一般店家的營業空間裡，此時機器的所有權及營運皆未移轉，甚至電玩業者還要支付土地租金給這些店家，此時程式碼便可被視為從未移轉到這些店家，而不用提供該機器的程式原始碼給任何人。

希望這些回答對你有所幫助，有後續問題可以接續討論。

敬祝 順心

20090603 2310 自由軟體鑄造場 林誠夏

Dear lucien,

謝謝您的答覆，讓我對這授權議題有了更深的了解。

看完了您的回覆之後，我想到了另外一個問題，抱歉問題有點多，因為我對這方面還蠻有興趣的：

您回覆提到關於「程式能主張獨立性(independent and separate)」這一點，我覺得似乎有討論的空間，因為程式之間的溝通，不見得是靜態或動態聯結，也可能是經由網路或是經由資料庫所儲存的資料來交換資訊。那麼，如果有一隻程式，它雖然是 GPL 授權，但是可經由網路來與它連結並彼此交換資料，這樣難道就可以規避 GPL 感染問題嗎？

同樣的情況，如果某 GPL 程式它將產生的資訊存入資料庫，而我們自己的程式藉由這些資料來產生需要的內容，中間經過了一層資料庫，難道就可以不受到 GPL 影響？

還請不吝賜教，謝謝

Hi williewu,

你問的問題其實蠻深入，一針見血就戳到GPL授權爭議糾結的點上

下面是我對這二個問題的意見。

1、透過網路連結的方式與存取交換GPL授權程式的資料，就可以規避GPL授權程式的感染性嗎?

是的、原則上確實如此，這也就是為什麼自由軟體基金會在2007年6月29日公布了GPL3的版本後，旋即於同年11月19號公布了AGPL3的孿生版本。

AGPL3的全名為GNU Affero General Public License Version 3，其全文連結如右：https://www.fsf.org/licensing/licenses/agpl-3.0.html

之所以稱AGPL3為GPL3的孿生版本，那是因為除了第13款的內容之外它們完全相同：

13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

13款主要就是在講，如果程式是以AGPL3授權釋出的話，那麼就算是以「網路連結」的方式使用它，也會開啟AGPL3授權程式的授權拘束性/授權感染性，從這個觀點來解釋，是的、一般來說GPL3或是GPL2的軟體，以網路連結的方式來存取它原則上是可以規避到GPL授權程式的授權拘束性的，但是這樣的行為也可能會被禁止，因為若是程式的著作權人認為這樣的規避不能接受，那從2007年11月19號之後，他們可以改用AGPL3來釋出他們的軟體，以 AGPL3授權的軟體，就會防堵掉利用網路存取所能規避掉的義務性規定。

2、透過中介隔層的資料庫軟體來存取GPL授權程式的資料，就可以規避GPL授權程式的感染性嗎?

是的、現實狀態似乎是如此，但這討論來會是長篇大論，所以我直接提供二個範本來讓大家思考，第一個就是現在非常著名正火速發展的Google Android開發平台，第二個就是應用在Driver編寫方面的UIO規避手段。



上圖為Google Android的授權架構圖，低層為GPL2授權的Linux Kernel，中介的是bsd-like或是LGPL授權的Library以及Apache2.0授權的Runtime，函式庫之上還有中介AP及函式庫的AP Framework，最上層才是讓個別廠商自行開發的應用程式，最上層的應用程式廠商可以自己決定提供程式原始碼與否，不受到GPL2授權的Linux Kernel限制，這樣的中介規避架構在GPL3裡著墨甚多，一般認為這樣是Well defined Interface，也就是說AP層只與Library層溝通，Kernel層也只與Library層溝通，AP層並不會直接與Kernel層溝通，現實面很多人認為如此一來AP層的應用程式可以主張「並非Linux Kernel層的衍生著作(Derivative Works)」，從而可以不受到Kernel層GPL2授權程式的拘束。

但當然、這樣的作法不是完全沒有爭議，Google Android可以運行這樣的中介規避，還有很重要的一層因素是因為Linux Kernel核心開發者對於GPL2的解釋態度較為寬鬆，Linus Trovolds的相關評論可以參閱這個連結：https://cvs.fedora.redhat.com/viewvc/rpms/kernel/devel/COPYING.modules?view=co，所以並不能保證每個GPL授權程式都必然可以用中介規避的方式來把感染性完全區隔掉，很多不同狀況的案例還是得視個案的情況進行判定。

而另一種Driver方面的UIO中介規避模式(the user space I/O system)，其實也與Android的狀況十分類同，它也是在AP及Kernel之間隔一層以LGPL或是BSD、MIT等，可以為GPL授權方式「吸納同化」的函式庫程式做為中介，然後將 Driver的重要演算法寫在AP的層級，以運作在User Space的方式透過中介的Library與Linux Kernel間進行呼叫，這樣的方式、也有很多人認為，寫在AP層級的Driver，是不必受到Linux Kernel授權拘束性約束的(但是中隔的Library層就一定要選擇和GPL相容的授權方式釋出)。

Carsten Emde於2008年11月的演講簡報，綱舉目張的解釋了這樣的運作概念(第八頁)：https://www.osadl.org/fileadmin/dam/presentations/FAPI-UIO-SPS-2008.pdf，你可以下載這份簡報供作參考之用。

希望上述回答對你有所幫助。

敬祝 順心愉快

20090604 1305 自由軟體鑄造場 林誠夏

沒想到這個小問題可以得到這麼詳細的答案，讓我對 GPL 感染這方面的議題有了更深一層的了解，十分感謝！！

但是在回過頭去參考版上其他篇的文章後，有些地方我覺得觀念還不是很清楚，還請不吝指教：

就如同我前面提到的疑問，程式或行程間溝通的方式有很多種，既然經由網路的方式可以避開 GPL 感染，那如果是透過 unix socket，或是 pipe 來溝通，那不也可以避開 GPL 感染？因為我覺得這類的溝通介面其實非常相像，除了 internet socket 可經由 "網際網路" 來讓處在兩個不同實體機器的程式做溝通，unix socket / pipe 無法跨越不同的實體機器的差別外，我覺得其溝通的方式算是同一類的。

可是如果這樣可以避開感染，那在另外一篇 "以 command line 使用GPL 程式的授權問題" 討論所提到的：


GPL程式的授權承繼性/感染性原則上會在三種情況下開啟，一是修改感染、二是取用感染、三是結合感染(link、merge、combine)


那如果某 command line 程式是 GPL 授權，可是可以經由 internet socket / unix socket / pipe 來傳遞資料，那我們如果寫了一隻程式來呼叫它，該如何判斷其感染性原則？

另外一個小疑問是，不知道 GPL 感染性有沒有擴及到設定檔？我會如此一問是因為，有很多 GPL 程式可以經由修改設定檔的方式，來讓其所接收或產生的資料 (不曉得這接收或產生這兩種情況會不會造成差別) 可以經由 socket 或 pipe 傳遞，我們可以寫程式來接收其資料，那像這樣的情況感染性該如何判斷？

謝謝您的指教。