Hi Elic,
關於GPL授權元件的授權拘束性，進一步的細節可以參照拙撰，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍：
https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01
而您描述的將GPL元件，單純以「被執行、被呼叫」的方式來進行利用，原則上若是該GPL授權元件的開發社群持較寬鬆的立場來解讀的話，一般來說是會被認為此為using the GPL Program的狀態，而非work based on the GPL Program的狀態，而不致於讓整個軟體專案的程式碼，都必須依GPL授權的模式來向後散布，然而、有幾項要點必須在應用上去注意到：
1、若整個軟體專案是以散布的方式來提供，則附隨散布的GPL元件，即使是以目的碼格式(Binary Form)的方式來散布，仍然必須附隨一份源碼(Source Code)格式的檔案，提供給後手，或是指明此特定元件是以GPL授權的方式來散布，嗣後如果消費者或後手需要這部份的源碼格式(Source Form)，便可以再向散布者來請求得到源碼格式。
2、由於整個軟體專案其中一部份仍是GPL授權的，所以散布上必須要夾附一份GPL授權條款的全文，電子格式全文或是紙本全文皆可。
3、除了提供GPL授權條款全文之外，也必須在散布整個軟體專案時，對該專案內含GPL授權元件做基礎的標示，關於標示的方式，亦可參照葛冬梅小姐與我合作編撰的文章，自由軟體授權資訊的標示說明與 SPDX：
https://www.openfoundry.org/tw/legal-column-list/8420-license-info-of-floss-and-spdx
4、除了上述這些義務性規定之外，我個人建議您可以將整個軟體專案中其他元件如何與此GPL元件產生互動的相關互動資訊及以協定，填註在REAME或是INSTALLATION這樣的檔案中，此一作為是再提升其他元件主張「獨立性」的依據，這些互動資訊及協定，如果能做到該GPL授權元件在改版之後，其他的軟體工程師亦可依照您所提供的資訊，按圖索驥的將專案裡的其他元件重啟與此GPL授權元件的互動關係與連結，則您所開發的軟體專案之於此GPL授權元件的獨立性將更為穩固，而不會受到質疑。
大概資訊如上，希望對您有所幫助。
20130813 11:35 LUCIEN C.H. LIN
Favoured: 0
