你好：
從EPL 授權中允許自行開發的module或plug-in 若是獨立於原程式以外、非屬原程式的衍生作品, 可以不用公開程式碼. 但是
1. 如果Eclipse tool 中因為開發C程式需要使用到GNU toolchain 如GCC compiler, 以.exe 方式呼叫執行並且未對GCC 有任何修改. 這時自行開發的plug-in 也要遵循GPL 開放原始碼嗎?
2. 承上如果有修改到GCC compiler, 也是以.exe 方式呼叫執行. 那麼只要開放GCC 相關程式碼即可, 或是自行開發的plug-in 也要遵循GPL 開放原始碼嗎?

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

Hi LUCIEN:
感謝你詳細的回答, 我有兩個基本概念問題,
1. 如果我們開發的Eclipse IDE tool 有新增10個plug-in假設其中一個必須遵循GPL, 那是否也代表其餘9個plug-in 也須遵循GPL？ 因為所有plug-in都是在整個Eclipse IDE tool中.
2. 若今天是自己所開發的一個程式, 裡面包含10個module 且其中一個module 需遵循GPL, 是否也代表我整個程式都要遵循GPL. 我不清楚GPL 的感染界定

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

Hi LUCIEN:
謝謝你的回覆, 另一個問題請教, ARM也有基於Eclipse 所開發的IDE tool叫DS-5, 而從他的官網上有分professional edition, community edition, Customized edition. 而community edition 是free而且功能也比professional少. 而Customized edition 又是幫客戶客製化需要付費的版本, 不是很清楚他的商業模式.

1. community edition 和 professional edition 功能差異的部份算是ARM自行開發的獨立模組, 所以不用公開是嗎? 而ARM為何還需要釋放community edition?

2. ARM 幫客戶客製化的付費版本模式有算是雙重授權嗎？ 而ARM的客製化版本也須遵循EPL嗎？

相關資料如下:
DS-5 version:
ds.arm.com/
ds.arm.com/ds-5-community-edition/
ds.arm.com/ds-5/compare-ds-5-editions/
www.arm.com/products/tools/software-tools/ds-5/compare-arm-ds5-editions.php

DS-5 license:
dl.dropboxusercontent.com/u/28129828/DS-5%20license.rtf

Hi MilesChou,

DS-5之所以會有professional edition、community edition，而僅有community edition是延用EPL授權方式釋出，而其他專業版本或客製化版本(Customized edition)都有試用期限與價金收取，其實就是其利用EPL與其他開源授權，明訂授權拘束範圍的機制，所發展出來的商業模式！

以EPL(Eclipse Public License)授權元件為例，其授權拘束的運作要點有：
1、修改以EPL授權的部份，後續衍生物一樣要以EPL來散布與授權。
2、非直接衍生自EPL授權元件程式碼的部份，如在功能上為獨立模組(module)，則可以在後續散布由其撰寫人自擇不與EPL衝突的其他授權條款，或直接採用商業授權條款。

所以在這樣的原則上：

DS-5這個軟體專案的主框架，依據您所提供的右列文件(dl.dropboxusercontent.com/u/28129828/DS-5%20license.rtf)，是屬於共享軟體(Shareware)的授權狀態，也就是說，整包程式碼可以被拿來試用，但除了其中本來就是以自由開源軟體授權的部份，其餘部份並不是都以自由開源授權的方式提供給使用者。參照這份文件標註為「SECTION 2 - SEPARATE FILES」的部份，可以看到：Java、The Eclipse IDE、部份的ARM plug-in、他方採用到的Libraries，還有屬於Windows的Windows Driver Development Kit，都延用其Open Source的授權方式，以及第三方本來的授權方式。

所以說，DS-5其實是組合了許多的開源專案與共享軟體元件，採主框架與插件(plugin)、模組(module)授權分立的方式釋出，例如VLC、FFMPEG、或是Mozilla Firefox這些著名專案，也都有這樣的情況！進一步的相關資訊，您可以參閱葛冬梅小姐撰寫的專文，淺析自由開源軟體專案與其個別元件授權條款之差異：www.openfoundry.org/tw/legal-column-list/9097-the-difference-of-licenses-between-a-foss-project-and-its-components，該文對這樣的狀況，已有清晰的描述。

所以，DS-5也算是走一部份這樣的模式，其專案主要的程式框架，是採自行訂立的規則釋出，然而，其中部份的插件與加效模組，是延用自由開源軟體的授權方式，這樣的配置，您如果下載的是DS-5的社群/輕簡功能版本，自然功能是較為簡陋的狀態，而付費購買其完整功能或客製化功能版本，才會一併得到這些私有授權模組的使用授權。

希望上述這些資訊，有助於您釐清疑惑，如後續有衍生的想法或問題，也歡迎您隨時接續在此討論。

敬祝 順心健康、事事如意



20131126 17:35 LUCIEN C.H. LIN