您好、簡短回覆您的問題如下：
問題1、以command line的方式直接利用GPL2授權的Swftools-binary執行檔，是否會開啟GPL授權程式的授權承繼性/授權感染性?
GPL程式的授權承繼性/感染性原則上會在三種情況下開啟，一是修改感染、二是取用感染、三是結合感染(link、merge、combine)，依照您所描述的情況，重點應該不是用哪一種方式來呼叫GPL2授權的Swftools，而應該是：1、是否會被判定是結合感染(link、merge、combine)?2、若然被視為結合感染，該產品對於GPL2授權的Swftools是否具有依賴性?若是失去了Swftools的支援則整個產品大部份的功能都會消失?
若是上列二個問題都不能免除，那麼以command line的方式利用GPL2授權的程式一樣會開啟GPL授權程式的授權承繼性/授權感染性。
問題2、將GPL2授權的Swftools程式內含於產品中一併散布，是否合乎GPL授權程式的使用規定?
將GPL2程式合併於產品一併釋出並不會違反GPL的授權規定，然而如果符合「結合感染」的範疇，那整個產品的授權狀態都會被GPL授權條款所影響，最後可能整個產品都只能用GPL授權方式來釋出。
問題3、如果產品出貨時不內含GPL2授權的Swftools程式，嗣後再讓使用者自行由網路下載Swftools的binary檔案與主產品結合，如此一來是否產品不用受到GPL授權承繼性/授權感染性的拘束?這樣的規避方式是否有違反GPL授權條款?
就法律狀態而言，產品出貨時並不包含GPL授權程式碼的話，就不會開啟GPL授權程式的授權承繼性/感染性，然後、一旦這個產品嗣後下載了GPL授權的程式碼並與之結合，那結合後的產品便向後受到GPL授權程式的拘束，所以這個嗣後程式碼結合的動作，需要由產品的買受者、消費者、終端使用者在「完全自主的意思狀態下為之」，產品的販售者才可以免除提供整個產品程式原始碼的責任，也就是說嗣後結合GPL授權程式碼的動作由誰施行，那後續提供整體產品程式原始碼的責任便歸誰，所以說如果產品的出貨廠商是以「自動化方式」幫助產品使用者後續下載這些GPL授權的程式到產品裡，那麼提供整體產品程式原始碼的義務還是歸於產品的販售者身上。
另外、產品出貨時不內含GPL2授權的程式，嗣後再讓使用者自行由網路下載後作結合的作法，雖然法律狀態下並不直接在文意上違反GPL授權條款的規定，但若是此一產品缺乏了相關的GPL授權程式則淪喪了大部份的產品功能，則在判定上還是會被視為對於GPL授權條款的惡意規避，雖然因起訴舉證上的困難及相爭事實繁複，導致法律狀態下較不易為原GPL程式著作權人視為起訴的對象，但仍然可以引發網路社群參與者的惡評，進而影響到公司商譽及形象。
問題4、相關產品是一個硬體設施，採用了GPL授權的作業系統(例如LINUX KERNEL2.6)，實際的產品功能是運作在JRE與Tomcat之下，此一產品是否可以不受到GPL授權承繼性/感染性的拘束?如果會的話，是否改採用FreeBSD的作業系統便可以不受到拘束?
如果不開放程式碼的私有軟體是處在AP(Application Program)層級的話，那規避GPL授權承繼性/感染性的可能性比較高，例如GOOGLE的Android平台就是這樣的作法：
www.android.com/；然而在硬體產品如果是driver的層級，因為驅動程式直接與Linux Kernel直接產生連結關係，這樣的規避難度是比較高的，部份廠商是有用中介的方式把driver寫到ap的層級，但實際操作上要多耗費許多的工時，亦未必經濟。若是所耗費工時過久，如您所言、改採用BSD授權的低層作業環境會是一個比較保險的選擇。
有後續問題歡迎接續討論。
祝 好
20090402 1200 自由軟體鑄造場 林誠夏
Favoured: 0
