Hi ckui,
謝謝您提供的資訊，閱讀過之後覺得Sencha確實是一個有趣的自由開源專案。
1、授權說明主頁面表達其同時具有商業授權版本，以及GPL-3.0的授權版本：
https://www.sencha.com/products/extjs/license/，通常此種Dual-license模式下，因為要讓使用者盡量去購買商業授權的版本，對於Open Source的那個授權方式，在解釋上都會傾向較為嚴格。
2、
https://www.sencha.com/legal/open-source-faq/open-source-license-exception-for-development/，使用Sencha程式框架及函式庫來開發自己的開發工具時，所可以適用的除外條款。此處主要表達的是，Sencha容許這些外掛或是額外撰寫的工具模組可以用列表裡的「其他自由開源授權條款」來授權，這是它不完全同於GPL-3.0的除外條款。
3、
https://www.sencha.com/legal/open-source-faq/open-source-license-exception-for-applications/，應用程式內嵌或是直接連結Sencha程式框架及函式庫來運作的話，所可以適用的除外條款。此處主要表達的是，Sencha容許這些應用程式裡，使用者自行撰寫的部份，可以適用列表裡的「其他自由開源授權條款」來授權，這亦是它不完全同於GPL-3.0的除外條款。
那麼、根據上面的重要資訊，來簡要回覆您提出來的問題。
一、採用類似Android的方式來釋出與Sencha軟體框架互動溝通(interacting)的中介隔層，是否此一開發工具的其他模組，就可以不受到GPL-3.0授權條款的拘束，而可以使用自我律定的其他授權方式來散布？
簡答：理論上是可以的，但實際狀況還是要看「中介隔層的縝密度與可移植性」，才能將GPL授權拘束的爭議性降到最低，因為我個人認為Sencha之所以在其Framework及Library之上，加設一個GPL-3.0的豁免條款，但又再額外限制這些自行撰寫的工具模組，「必須要用列表內的其他自由開源軟體授權條款」來授權，其要放寬GPL-3.0授權拘束性的對象，應該不會是一個簡易的中介隔層背後close source的商業軟體，反而、其要達到的目的，很可能是提升Sencha Framework、Libraries與「其他自由開源軟體元件」的相容性！
一般來說Google Android的中隔作法，在程式互動與授權規劃的可能作法如右所示下（箭頭代表程式與程式之間的呼叫互動性）：
Sencha Framework + Sencha Libraries（GPL-3.0授權）→←中介隔層（Apache-2.0或其他表列的開放授權方式）→←其他的開發工具模組（預計使用自己選擇的商業授權方式）
也就是說、透過一個開放授權的中介隔層，來讓只和中介隔層的其他開發工具模組，可以用傳統close source的軟體授權模式來散布；然而、這樣的作法，這個中介隔層必須要縝密具實際上well defined而可以讓許多不同的工具模組來呼叫，而若是其僅是傳遞特定工具模組與GPL授權元件的溝通訊息，則可能會被認為是一種實質的規避，而會被論以與其後的工具模組為一整個作品，而一併受到GPL-3.0授權方式的拘束。
我個人認為從Sencha專案的雙重授權策略來看，其想要透過GPL-3.0 Exception促成的利用模式，會比較接近下列這個方式：
Sencha Framework + Sencha Libraries（GPL-3.0授權）→←中介隔層（Apache-2.0或其他表列的開放授權方式）→←其他的開發工具模組（其他已然成熟的自由開源專案，但直接merge時並不相容於GPL-3.0的授權方式。）
會有這樣的析論，是因為許多自由開源專案的開發者，確實有意識到實際應用時，與GPL授權元件相容的重要性，例如David Wheeler撰寫的這篇專文即解釋了這樣的重要性：
https://www.dwheeler.com/essays/gpl-compatible.html（提供對照參考的中譯版本，可參照右列連結：
https://lucien.cc/?p=22），所以我認為關鍵點在於Sencha採用了Dual License的授權方式，原則上便是要利用GPL-3.0具強質授權拘束性的授權方式，來推促認為授權拘束性妨礙商業利用的使用者，可另外與其洽談商業授權的模式，故即使其在GPL-3.0授權方式上加上了除外條款，但在區隔中介方面的解釋，應仍是會類同MySQL、QT一般，從較嚴格的方向來解釋，而沒有辦法用簡易中介隔層的方式，就將其免除掉。
二、Sencha Exception條款的第五點「Your Extension can reasonably be considered to be adding to or modifying standard functionality of the Library for software development purposes and does not constitute an independent and separate application in itself.」的指稱方式究竟為何？
就這點解釋上，我是認為就是一個補充說明，按GPL-3.0原來的授權方式，其他元件即使與GPL-3.0的程式併行運作，但若是以「independent and separate」的方式來互動的話，則彼此之間並不生授權拘束性的關係。所以我認為Sencha Exception條款的第五點，只是在提醒使用者，若您自行撰寫程式與Sencha Framework與Libraries的互動方式本來就是「independent and separate」的話，則本來就不生授權拘束性的問題，但若此一工具模組、確實是對於Sencha Framework與Libraries的標準功能有進行修改，那此時就不符合「independent and separate」的定義範圍，而要受到Sencha所適用GPL-3.0條款的授權拘束，而一併使用GPL-3.0的授權方式來向後釋出，而此時、若此工具模組的開發者認為以GPL-3.0的方式釋出此工具模組並不合乎規劃，則可再援引Sencha專案的exception條款，而改以列表裡的Apache-2.0或是其他較不具授權拘束性的自由開源授權條款，來釋出此一工具模組！
希望上述的分析資訊對您有所幫助，若有後續疑問歡迎接續提出討論！
敬祝 順心健康、事事如意
20111104 1800 LUCIEN C.H. LIN
Favoured: 0
