你好，
我現在有二個程式，我希望
程式Ａ：open source
程式B ：not open source
不知道有沒有可行性，適合哪一種license。
我現在想到二個方法，想請教一下可不可行，
方案一：利用Ａ（exe）呼叫Ｂ(dll)
方案二：利用Ｂ（exe）呼叫Ａ(dll)
請問有可行性嗎？

yycking 撰寫:
你好，
我現在有二個程式，我希望
程式Ａ：open source
程式B ：not open source
不知道有沒有可行性，適合哪一種license。
我現在想到二個方法，想請教一下可不可行，
方案一：利用Ａ（exe）呼叫Ｂ(dll)
方案二：利用Ｂ（exe）呼叫Ａ(dll)
請問有可行性嗎？

哈囉、我看了一會有點捉不到重點，
是說程式A與程式B都是你寫的「原生著作」嗎?
所謂「原生著作」的意思是程式都是由你自行撰寫，
沒有抄寫其他人的程式碼，
如果是這種狀況的話，
那程式A及程式B你可以任選任何一種自由軟體授權條款，
譬如程式A用MIT License釋出，
程式B可以任擇其它的授權條款，
甚至此時程式B用Proprietary Software的型式不提供程式原始碼。

但是!

問題是如果程式A你要採用的是GPL、MPL、CPL類具有Copyleft性質的授權條款，
那爭議性就會比較大，
以GPL授權條款為例，
程式A及程式B之間的「呼叫關係」如果是密不可分的話，
很多人會依GPL授權條款嚴格的文意解釋認為，
這時候程式A及程式B應該統一授權狀態，
那我提出來的看法是，
重點還是要看程式A及程式B之間的「依賴關係」有多明顯，
倘若這個不提供程式原始碼的程式B，
它相對於主程式A是一個功能的元件(Component)、插件(Plugin)、甚至只是造型模組(Template)，
1、程式A缺乏了程式B還是可以運行基本功能。
2、程式B能夠與程式A分開散布，雖然結合了程式B的功能整個軟體專利有「加分」的效果，但失去程式B並不會導致程式A無法運作。
如果滿足了上述二個要件，
那麼在「獨立性」的解釋上，
程式B的授權狀態是可以不用受到程式A的拘束的，
不知道這樣的方法對你來說是否可行?

有後續疑問的話歡迎再補充細節。

祝 好

20081211 1000 自由軟體鑄造場 林誠夏

抱歉，我的說明寫的不夠清楚。
我現在有主程式Ａ（Proprietary Software），
程式B是scripting language（ex: perl, python, ruby）。
當Ａ在執行時，可以直接呼叫Ｂ來執行。也就是Ｂ是Ａ的Plugin。
我的問題是如果Ａ是Proprietary Software，Ｂ可以是自由軟體授權（ex gpl）之類的嗎？

如果是A叫B這個獨立的程式工作,這兩個程式應該沒有關聯吧,
也就是B要用什麼授權都可以.

(我猜的)

yycking 撰寫:
抱歉，我的說明寫的不夠清楚。
我現在有主程式Ａ（Proprietary Software），
程式B是scripting language（ex: perl, python, ruby）。
當Ａ在執行時，可以直接呼叫Ｂ來執行。也就是Ｂ是Ａ的Plugin。
我的問題是如果Ａ是Proprietary Software，Ｂ可以是自由軟體授權（ex gpl）之類的嗎？

有主程式A(Proprietary Software)，
程式B是scripting language(例如perl, python, ruby)。
當Ａ在執行時，可以直接呼叫Ｂ來執行。也就是Ｂ是Ａ的Plugin。
如果Ａ是Proprietary Software，Ｂ可以是自由軟體授權(例如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 自由軟體鑄造場　林誠夏