Hi MilesChou,

您所提的二個問題，第一個問題沒有什麼疑慮，因為GCC Compiler這個專案的程式碼撰寫人員，過去幾年彼此間已經進行了充份討論，並且還明文訂出GCC RUNTIME LIBRARY EXCEPTION這樣的額外容許宣言：https://www.gnu.org/licenses/gcc-exception-3.1.html

所謂的GCC RUNTIME LIBRARY EXCEPTION(編譯動作的額外容許條款)大致上就是：當您使用GCC Compiler來編譯程式元件時，此一自動化的編譯過程，不會讓您自行撰寫的程式元件成為GCC Compiler的衍生著作，即使在編譯過程中，有部份GCC Compiler的程式碼會匯入到被編譯元件之中，只要這些程式碼是因為GCC Compiler執行編譯過程(RUNTIME)會自動編譯進去的，就不會啟動GPL授權程式的授權拘束性(License Inheritance)。

所以說，對照您所提發的第一個問題：如果Eclipse tool中因為開發C程式需要使用到GNU toolchain中的GCC compiler，而使用GCC compiler的方式，是以呼叫.exe執行檔的方式，獨立呼叫GCC compiler來執行編譯功能，並且未對GCC compiler有任何的修改，此時由您自行開發，且經GCC compiler編譯過的軟體插件(plug-in)，是沒有被要求一定得遵循GPL授權條款的規則來向後散布的！

關於GCC RUNTIME LIBRARY EXCEPTION細部的運作說明，亦可以參照GNU Project右列的說明頁面：https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

那接著第二個問題，其實論理架構與第一個問題相仿，只要確定這個「修改過後的GCC compiler，也是採用GPL-3.0 + GCC RUNTIME LIBRARY EXCEPTION」的方式來授權，就可以得出一樣的結論。所以如果這個GCC compiler是由您自己修改的，您便可以讓其沿用「GPL-3.0 + GCC RUNTIME LIBRARY EXCEPTION」的原始授權模式，而得出編譯軟體插件(plugin)不會開啟GPL授權拘束性的結論；而若是您採用的是GNU Project官方釋出的GCC Compiler，一樣也是依循「GPL-3.0 + GCC RUNTIME LIBRARY EXCEPTION」這個授權模式，但！因為GCC Compiler此一「GCC RUNTIME LIBRARY EXCEPTION」，是依循GPL-3.0第7條額外添附條款(additional terms)的規則來添加的，在必要時，後手修改者可以在自行的修改版本中，把這樣的「額外容許(EXCEPTION)」移除掉，所以如果您所取用的GCC compiler：既非您自行修改的、亦非GNU Project的官方釋出版本，而是其他開源社群朋友自行分枝(fork)出去的衍生版本，則就要進一步確認這個衍生版本是不是也承襲了「GPL-3.0 + GCC RUNTIME LIBRARY EXCEPTION」這個預設的授權模式，若是，則用其來編譯軟體插件，仍然不會開啟GPL授權元件的授權拘束性，但若是該分枝版本已將「額外容許(EXCEPTION)」的聲明移除掉，則該被編譯的軟體插件，就有可能會被認定必須要依GPL的授權規則來散布。

不過，雖然說您提問的使用狀態應該不是下列的狀況，但還是提醒一下，若您所開發的軟體插件(plugin)，並非對Eclipse tool的補強，而是直接就是參考GCC compiler的架構所寫出的軟體插件，也就是說，該插件是針對GCC compiler所撰寫的軟體插件，那麼依照GNU Project的觀點，該GCC compiler的Plugin是該用GPL-3.0的方式來授權，相關的編譯新聞亦羅列在右方，供您參考：https://www.openfoundry.org/index.php?option=com_content&task=view&id=1971&Itemid=144

大致授權分析的狀況如上所述，希望這些資訊對您有所幫助，若後續還有衍生想法，歡迎接續討論。



20131115 14:10 LUCIEN C.H. LIN