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