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 自由軟體鑄造場 林誠夏