Hi MilesChou，

這兩個問題的基本答覆，還是要看個案與元件之間的運作狀況來論，簡要來說，如果個別plugin或module之間的運作狀態是獨立的，則這些plugin與module的授權狀態並不致於互相影響，但如果個別plugin或module之間，其實必須透過主程式框架來交互運作，則可能彼此之間還是會被認定為衍生關係，而有授權承繼與拘束之間的問題需要進一步釐清。

對於GPL授權元件的擴散範圍，過往我曾寫過下例二篇文章，供您作一個參照：

GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01
GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）：https://www.openfoundry.org/legal-column/8447

就上述的基礎，就您提出的問題來進行分析：

1、如果自行開發的Eclipse IDE tool裡，新增了10個plug-in，假設其中一個會被視為GPL授權程式的衍生著作，那是否代表其餘9個plug-in也必須遵循GPL？

不一定，倘若：1、此一Eclipse IDE tool本身以開源的方式釋出；2、此一GPL授權的plug-in負責特殊功能，但僅在要運作此功能時，才會被Eclipse IDE tool的主要程式框架呼叫出來(例如將分析結果圖表化)；3、其他plug-in運作自己的功能時，並不依賴此一GPL授權plug-in的功能，而是僅與IDE主框架互動。若是上述三個條件皆符合，那一般來說此一GPL授權plug-in的授權狀態，不致於影響到其他的plug-in。

然而，若是其他plug-in在運作上，高度依賴GPL授權的plug-in，或從研發歷程來說，確實是參照GPL授權plug-in的程式架構來進行撰寫，那麼此時量變會產生質變，這些plug-in便有可能因為運作上的相依性，或是程式寫作上的架構承繼性，而被認定為GPL授權plug-in的「衍生著作(derivative work)」，此時，這些plug-in便有可能，會被要求必須遵循GPL的授權規則來進行後續散布。

2、若今天自行開發一個程式，裡面包含10個module，而其中一個module必須遵循GPL的授權規則，是否代表整個程式都必須要遵循GPL？

這個問題其實和上述的狀況高度近似，所以結論也是相近的。只不過，上例中Eclipse IDE tool本身是開源的，故程式與程式之間的運作獨立性比較容易進行分說，這也是為何Google Android平台，會以開源授權的方式來建立中隔層(middle layer)，以阻隔Linux Kernel為GPL-2.0授權的拘束特性。故而您此處提到「自行開發的程式」，若本身並非開源，則可能解釋上必須佐以其他更有力的論述，例如：該GPL授權的module，亦可為BSD或MIT授權的其他module來取代，如此一來，能證明整個程式的運作並非拘執於GPL授權的module，如能達到此一論述，那一般多會同意該程式並不必然為GPL授權module的衍生著作。

大致是這樣，希望上述的資訊，對您釐清困擾有所幫助。



20131121 15:55 LUCIEN C.H. LIN