yycking 撰寫:
抱歉,我的說明寫的不夠清楚。
我現在有主程式A(Proprietary Software),
程式B是scripting language(ex: perl, python, ruby)。
當A在執行時,可以直接呼叫B來執行。也就是B是A的Plugin。
我的問題是如果A是Proprietary Software,B可以是自由軟體授權(ex gpl)之類的嗎?
有主程式A(Proprietary Software),
程式B是scripting language(例如perl, python, ruby)。
當A在執行時,可以直接呼叫B來執行。也就是B是A的Plugin。
如果A是Proprietary Software,B可以是自由軟體授權(例如GPL)的程式嗎?
Okay、了解了,基本上就我的理解,這還是一個GPL感染性的問題。
用比較複雜但正式一點的文字來改寫這個問題,就是:「將自由/開放源碼軟體(Free/Open Source Software, FOSS)與私有軟體(Proprietary Software)進行結合運用,該自由/開放源碼軟體會不會去影響到該私有軟體的授權狀態?
可能會、也可能不會,這要看你解釋GPL授權條款角度的嚴謹程度。
可能會、也可能不會,也要看該私有軟體與這個「自由/開放源碼軟體」之間的結合密度及依存關係。
就GPL授權條款的解釋,其他程式與GPL程式有結合關係(Link, Merge, Combine)的話,該結合程式也要受到GPL授權條款的拘束,所以首先要判讀的,就是該不想開放程式原始碼的私有軟體(A),與該GPL程式( B )之間是否到達Link, Merge,以及Combine之間的關係。
那麼在Link的結合關係方面,有一些人是認為,如果這個連結關係是動態連結(Dynamic Link)的話,那代表該A程式是可以主張獨立性的,因為動態連結代表A程式的運作基本上並不完全依賴B程式,但這也只是一個原則,事實上有些連結關係即使是動態連結,A程式與B程式之間的結合關係仍然是密不可分。
其實重點還是在於A程式對於B程式的依賴狀況,如果A程式並不依賴B程式也可以存在,並運作大部份的基本功能,那麼在解釋上A程式就是具有「獨立性(Separate and independent work)」的程式,它的授權狀態就不會受到B程式的影響或是干擾,即使B程式是以GPL授權的程式亦然。
但是如果B程式對於A程式提供的功能,對整個軟體作品的表現來說是非常核心而重要的部份,那麼即使B部份寫的程式碼在整個軟體專案所佔的比例並不太多,還是有可能會被GPL授權條款解釋為「密切結合的同一軟體專案」,而讓整個軟體專案都只能用GPL授權條款來授權。
譬如FcEditor(
sourceforge.net/projects/fckeditor)及TinyMCE(
sourceforge.net/projects/tinymce/)都是著名的「所見即所得網頁編輯器」,現在有許多的Blog/CMS系統都以其為預設的文章編輯器,FcEditor是用GPL、LGPL、及MPL三重授權,TinyMCE則是用LGPL來授權,此例中如果某人寫了一個不開放原始碼的CMS系統,但是選用GPL授權的FcEditor為第一預設文章編輯器,但同時提供有LGPL授權的TinyMCE做為使用者另一可選擇的備案編輯器,那麼就筆者的理解,這時GPL授權版本的FcEditor的「感染性」,是不會過繼到CMS主系統。
第一點個思考點,CMS並非以「圖形式網頁編輯器」為必要元件,就算這個不開放原始碼的CMS系統少了FcEditor,它還是一個有基本功能的完整CMS系統,也就是說這個CMS系統還是能用,只是沒有那麼好用罷了,所以應不認為CMS系統對FcEditor這個網頁編輯器有依賴性;而第二個思考點,就算有論者認為CMS系統一定要有網頁編輯器,此例中這個不開放原始碼的CMS系統其實有LGPL授權的TinyMCE做為使用者的「第二備案」,所以該CMS對於GPL授權的FcEditor還是沒有「必然的依賴性」,反過來說、就可以主張不受FcEditor所適用的GPL授權條款所拘束。
前例是對於GPL這種授權較具拘束性/感染力的授權條款來解釋。
如果你要選用的程式B並不是帶有強烈拘束力的自由軟體授權條款,像是BSD或是MIT這類的授權條款,那麼原則上就不會有上述的問題,因為BSD或是MIT類別的授權程式,都不會干擾其他結合軟體的授權狀態,或者像MPL、CDDL,如果不是修改到以MPL或CDDL授權的程式檔案(FILE)本身,也不會有這種授權干擾的問題。所以說確實的答案還是要視個案而定,如果再有詳情我們接續再討論。
祝 好
20081226 1558 自由軟體鑄造場 林誠夏