Dear 華先生，
這個問題的關鍵點應該在於：該agent component會被視為一個獨立的程式？還是架構與運作上被視為，從屬於整個宣告為GPL授權主元件的衍生程式？
因為如果該agent component被視為獨立程式，則其本身在散布時就沒有一定要提供程式源碼義務，但如果該agent component被視為GPL授權主元件的從屬程式，則其散布上還是可能會引發要不要提供程式源碼的相關爭議。
用舉例示意的方式來說明，倘若該專案有Server端的程式元件A、以及Client端的程式元件B，Server端的程式元件A，已因為對GPL授權元件高度相依，而被判定為GPL授權元件的衍生程式的話，那麼僅能與該元件A互動而產生功能與服務內容的元件B，在解釋上也會被歸類為整體專案的一部份，而被要求統一使用GPL授權條款來向外散布。這部份的相關判定，可以參考GNU Project關於GPL FAQ的相關解釋：http://www.gnu.org/licenses/gpl-faq.html#MereAggregation
上述這個GPL FAQ的條目，我在自己個人用來學習、紀錄的wiki上也有進行中譯，可以在有需要的時候直接參照，「GPL授權條款中『聚合著作』與『修改著作』間的差異在哪裡，又彼此的區隔分界在哪？」：http://lucien.cc/lucien/doku/doku.php?id=notes_and_translations:frequently_asked_questions_about_the_gnu_licenses#gpl%E6%8E%88%E6%AC%8A%E6%A2%9D%E6%AC%BE%E4%B8%AD_%E8%81%9A%E5%90%88%E8%91%97%E4%BD%9C_%E8%88%87_%E4%BF%AE%E6%94%B9%E8%91%97%E4%BD%9C_%E9%96%93%E7%9A%84%E5%B7%AE%E7%95%B0%E5%9C%A8%E5%93%AA%E8%A3%A1_%E5%8F%88%E5%BD%BC%E6%AD%A4%E7%9A%84%E5%8D%80%E9%9A%94%E5%88%86%E7%95%8C%E5%9C%A8%E5%93%AA
而上述條目的重點，其實就是部份自由開源軟體社群，認為二隻程式若是透過pipes、sockets，或是command line的方式來彼此溝通，那原則上就是二個獨立著作，只是彼此聚合起來進行運作，此時即使其中一隻程式是採用GPL授權，也不會干擾到另一程式的授權狀態；然而、這只是一個大原則，然而、如果這二隻程式在資訊交換上有著相同結構的語彙邏輯，則就算彼此是透過pipes、sockets，或是command line的方式來溝通，但因為彼此交換的資訊具有層級上的相同性，且這樣的結合運作又被認定為關係密不可分，例如Client端的程式元件B與Server端的程式元件A共享一樣的資料層級及運作架構，且元件B失去元件A，本身即失去主要的運作功能的話，也有可能例外的被認定是同一個軟體程式的二個部份，此時若是負責主要運算與執行功能的元件A為GPL授權的話，則元件B也很可能會被認為得一併受到GPL授權方式的拘束。
前述採的是較嚴格的解釋態度，然而、實務上也可能因個案的情況不同，而有不同的解釋，從日前 Oracle vs Google的法院裁定，我們可以看到有時二隻程式共享一樣的API呼叫與存取資訊(http://www.theinquirer.net/inquirer/news/2181678/oracle-strikes-lawsuit-google-android)，也不一定能主張互動的B程式便為A程式的衍生著作。
所以、我的判斷是，貴所讓客戶自行下載agent程式來與GPL服務套件產生運作的方式，若是agent程式能做到不要內含該GPL服務套件程式碼的狀態的話，那麼後續可能引發授權爭議的風險性是小的，因為此時從法律面來分析，該agent並不內含GPL授權程式碼，則被認定為獨立著作的可能性大增，也比較站得住腳；而從技術面來分析，目前坊間已經開始有掃描binary code的軟體專案，這些專案能夠粗略辨識binary code有沒有使用到GPL授權的程式碼(http://www.binaryanalysis.org/en/content/show/tool)，而若是agent code裡面本來就不含GPL授權的程式碼，那自然透過binary code analysis tool來也不會查找到以GPL授權的程式碼。
反之、若是該agent程式內含了GPL授權的程式碼，則在法律面與技術面都會比較不利，因為當面臨GPL授權義務性違反的質疑時，可能就必須要有所說法、來向質疑方進行進一步的說明，例如解釋該agent程式不但能與伺服器端以GPL授權的元件A溝通，亦可與其他以BSD或是MIT授權的伺服器端元件C來溝通，來證明其運作上的「獨立性」。
約略的法律關係是這樣，至於這樣的服務架構能不能向客戶進行收費，原則上都是沒問題的，GPL授權的程式在應用上是可以進行商業收費的，前提只是收費名目不能是著作權與專利權授權金(royalty)，並且只要一散布了binary code，就必須同時或是嗣後提供Source Code給後手，除此之外，服務費用、建置費用、諮詢費用、維護費用…等等這些名目，都是可以進行收取的。
希望這些資訊對您有所幫助，後續若有疑問歡迎再接續討論。
:)
敬祝 順心健康、事事如意
20120608 1030 自由軟體鑄造場 林誠夏
TEL: 27883799 EXT.1474 CELL PHONE: 0987312414
華荐治 andy1688@cht.com.tw 於 2012年6月6日上午8:51 寫道：
Dear 誠夏：
另外一個議題想請教：
若自行研發的功能服務套件（使用到宣告為 GPL 授權的元件）係佈署於 Internet 上之特定機房環境中， 使用者取用服務前需自行下載 agent 安裝於電腦設備一次， 日後則統一使用瀏覽器連線至前述機房內之WEB伺服器取得所需功能與服務的使用權」。
在此種架構下若服務提供者欲向客戶收費時，是否有必須公開原始碼的問題？
非常謝謝您!
Thanks for your helping, and Best regards!
中華電信研究所 資通安全研究室
華荐治 敬上 03-4244182
