Hi MrLee,
基本上GPL授權元件的義務性要求與Apache-2.0模式的差異，主要就是授權拘束性(license inheritance)會不會啟動的問題。一般來說，您可以用以下二個最簡單的授權特性，來了解GPL授權條款：
1、散布了以GPL授權的目的碼(Binary Code)，從您手上取得此目的碼之人，就有資格同時或嗣後向您索取該GPL元件的程式源碼(Source Code)。
2、參照GPL授權元件所撰寫出來的衍生程式/衍生作品(derivative work)，後續再散布時，也必須使用GPL授權條款來向外提供(Work based on a GPL-ed program)。
所以，您原文述及Cacti、MRTG、Munin、Nagios，以及OpenNMS方案，這些方案的核心元件，都是採GPL授權條款來向外散布，若是取用其一放置到貴公司所研發的系統監控軟體之後，一併銷售(散布)給客戶，此類型的商業模式是絕對沒有問題，因為所有的自由開源軟體都不禁止商業利用(可參照GNU計畫專文，販售自由軟體：
www.gnu.org/philosophy/selling.html)，然而，其商業利用的模式，亦必須與個別自由開源軟體授權條款的授權義務(obligations)不會產生衝突才行。以您的例子來看，最重要的義務性規定，就是此一軟體建置專案裡，可能取用到GPL授權元件(Cacti、MRTG、Munin、Nagios、OpenNMS)的衍生範圍有多大，大致上是：
1、該專案裡其他的軟體元件與GPL元件之間的運作關係皆為獨立而分開(separate and independent)的狀況，則您在販售方案時，僅需要提供該GPL授權元件的程式源碼，以及說明此GPL元件如更新版本，應如何透過您所提供的安裝資訊與編譯腳本(installation information and compiling script)，來對專案或裝置裡的原GPL元件進行版本更新。
2、但倘若此專案專案裡有部份的軟體元件，確實是直接參照並根據GPL授權元件的架構來加以撰寫，那麼依照GPL授權條款的要求，此一元件便會被視為GPL授權元件的衍生著作(derivative work)，從而未來在運用時，也必須一併以GPL授權條款的方式來向外授權，也就是說，您在販售方案時，須提供的是原GPL授權元件的程式源碼，此些增補的衍生程式，以及說明此GPL元件配合衍生程式，應如何透過您所提供的安裝資訊與編譯腳本，來讓使用者得以進行後續版本更新的資料。
更多與GPL授權拘束性相關的資訊，可以參照拙著，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）：
www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01 ；GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）：
www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02 。
那麼，您原文提到在授權狀態上最為多元而複雜的是Nagios這個專案，所以以下，我便以Nagios為例，重點式的說明它的授權架構與應用方式。
----
NAGIOS是一個資源豐富且授權策略完整的開源專案，它初始是以GPL-2.0授權的版本為開發基礎，其後、原本的開發社群在專案規模愈大愈大之後，改而成立公司進行商業服務、但原本以GPL-2.0為授權基礎的專案仍有接續以開放源碼的方式在運作，目前在其公司頁面上以自由開源軟體授權方式釋出的版本為Nagios Core，而相對應的商業版本為Nagios XI，在透過Core或是XI建置好監控伺服器系統之後，另外還有Nagios Fusion(
www.nagios.com/products/nagiosfusion)與Nagios Mobile(
www.nagios.com/products/nagiosmobile)這些加值服務的軟體方案可以購買。
而就授權型態的不同來做區分，目前NAGIOS公司網站法律資訊頁面有提供三份授權條款的內容：GPL、Nagios Open Software License與Nagios Software License。也就是說、取得NAGIOS專案授權的方式不只有一種，而應用上的重點就是，視乎貴公司是用哪一種授權方式來取得NAGIOS專案程式碼的使用授權，大體來說、Nagios Open Software License是NAGIOS這家公司向社群朋友「收納程式碼」時所使用的條款，它是較偏向於BSD類型的方式，所以NAGIOS利用Nagios Open Software License的方式，是從貢獻者手上取得程式碼授權之後，不需改寫便可直接加入其GPL授權的版本與商業授權版本中進行運用。而就「釋出面」來說，Nagios Core釋出時所使用的授權方式是GPL-2.0，驗證的方式是從
www.nagios.com/products/nagioscore 頁面的連結下載原始碼，會連到NAGIOS在SourceForge上的開源專案，以NAGIOS-3.4.1版本為例 (
sourceforge.net/projects/nagios/files/nagios-3.x/nagios-3.4.1/nagios-3.4.1.tar.gz/download)，下載程式碼之後、解壓縮閱讀根目錄下的LICENSE檔案，確實就是以GPL-2.0為授權方式；而若是付費購買Nagios XI，則便會以Nagios Software License的方式來取得其程式碼授權。
簡要的說，如果取得的方式是商業版授權的NAGIOS，那麼就是依照Nagios Software License(
assets.nagios.com/licenses/nagios_software_license.txt)的方式來利用它，而若是直接從SourceForge專案頁面下載Nagios Core的版本，那就是依照GPL-2.0的授權規則來利用它，此時這個GPL-2.0授權版本的Nagios Core仍然可以被取為商業利用，但也必須去遵守GPL-2.0相關的義務性規定，故以下、就以GPL-2.0授權的Nagios Core為例來進行說明。
1、若是單純取用Nagis Core軟體，將其組合成解決方案進行服務。在這種模式之下，此一解決方案的提供者，除了Nagis Core這個元件以外，有義務要提供方案裡其他元件的程式源碼給客戶嗎？
可能要、可能不要，端視這個利用關係的細節是什麼。要確定此問題答案最重要的要點就是：此一解決方案的其他相關元件，會不會被視為Nagis Core的衍生著作？如果被視為衍生著作，那就必須承繼Nagios Core的授權方式，即以GPL-2.0來向後散布；如果不被視為衍生著作，那麼這些元件，就可以使用開發者自行選擇的授權方式。
判定是否衍生的第一個關鍵點在於其他元件是否有直接抄寫Nagis Core的程式碼，若是有抄寫一定份量程式碼的關係時，則此元件很容易就會被視為主程式的衍生程式，從而必須要依循GPL-2.0的授權方式來走；而第二個關鍵點在於相關元件與Nagis Core的參照程度與互動緊密性，然而、相關的判定必須在個案裡才可以得到充份的解答。因為著作權法對衍生著作的定義是「就原著作改作之創作為衍生著作(The work based on the original work)」，所以相關元件雖然可能沒有直接抄寫Nagis Core的程式碼，但必然會參考其運作架構以及層級架構，這樣的參照方式算不算是「就原著作」進行改作，在實務上還是要看解決方案裡各元件的互動與參照關係才能做判定。
那麼在此只能提供元件互動與參照關係的基礎說明，此部份的相關判定，可以參考GNU Project關於GPL FAQ的相關解釋：
www.gnu.org/licenses/gpl-faq.html#MereAggregation
我將此一QA做了簡要的中譯如下供您做個參考。
####
GPL授權條款中「聚合著作」與「修改著作」間的差異在哪裡，又彼此的區隔分界在哪？
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
所謂的「聚合著作」指的是許多獨立運作的程式，在散布時被儲放在同一個散布媒介，如CD光碟片上一同散布。GPL授權條款容許GPL程式能夠與其他程式，集結為聚合著作後合併散布，即使聚合著作裡其他的程式並非自由軟體，或者在授權狀態上是與GPL不相容亦可。此種作法唯一要注意的地方，就是整個聚合著作的授權方式，並不能去干涉聚合著作裡個別程式所本有的授權規則。
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
關於程式與程式間的聚合關係，究竟是二個獨立程式被合併儲放，或者是一個程式被切割為二個部份後儲放，這是一個法律問題，也就是說、有權做最後判定的是訴訟發生時的承審法官。不過、原則上，這樣的問題可以從二個層面來進行判定，一是程式與程式間的溝通機制的方式(例如：究竟是以exec、 pipes、rpc，或是呼叫function calls後在同一段共享記憶體區段執行的種種不同方式)，第二則是程式與程式間溝通語彙的內容(究竟這二個程式運作時交換的是哪類別的資料)。
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
所以、如果不同的程式模組已經被結合在同一個可執行檔中去運作，那此種結合狀態很明確的就是兩個程式被結合為一個單一程式。而如果是不同的程式模組，但在設計上預設會透過連結的方式，呼叫彼此到同一段共享記憶體去運作，那也幾乎可以表示這兩個模組其實就是一個單一程式的二個部份。
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
以比較的方式來解說，兩個獨立的程式常會透過pipes、sockets，或是下command-line的方式來結合運作。所以如果二個程式模組之間的構通機制是透過pipes、sockets，或是command line的方式，那這二個模組之間的結合關係，通常會被判定就是聚合著作而非程式彼此間的修改著作。然而、如果這二個程式模組在資訊交換上有著相同結構的語彙邏輯，則就算彼此是透過pipes、sockets，或是command line的方式來溝通，但因為彼此交換的資訊具有層級上的相同性，足證這樣的結合運作關係密不可分，故也有可能例外的被認定是同一個軟體程式的二部份。
####
上述QA的重點，其實就是部份自由開源軟體社群，認為二隻程式若是透過pipes、sockets，或是command line的方式來彼此溝通，那原則上就是二個獨立著作，只是彼此聚合起來進行運作，此時即使其中一隻程式是採用GPL授權，也不會干擾到另一程式的授權狀態；然而、這只是一個大原則，然而、如果這二隻程式在資訊交換上有著相同結構的語彙邏輯，則就算彼此是透過pipes、sockets，或是command line的方式來溝通，但因為彼此交換的資訊具有層級上的相同性，且這樣的結合運作又被認定為關係密不可分，例如Client端的程式元件B與Server端的程式元件A共享一樣的資料層級及運作架構，且元件B失去元件A，本身即失去主要的運作功能的話，也有可能例外的被認定是同一個軟體程式的二個部份，此時若是負責主要運算與執行功能的元件A為GPL授權的話，則元件B也很可能會被認為得一併受到GPL授權方式的拘束。
所以，依您所述，貴公司解決方案時僅需要取用任一款GPL授權的系統監控軟體即可，那麼實務上的作法與建議就是，若在機制上能讓該解決方案同時可以擇一開啟Nagios Core與其他監控元件的功能(Cacti、MRTG、Munin、OpenNMS)，那麼原則上您的整體解決方案的其他元件，原則上便取得了「獨立性」，因為此時系統監控功能，並不必然依賴於Nagios Core來呈現，而也可以取用其他Cacti、MRTG、Munin、OpenNMS的方案來取代，此時專案裡的其他元件，便不會被視為特別依賴於某一個GPL授權元件，從而鬆開了GPL授權衍生與拘束方面的爭議。
2、若是我們提供結果GPL授權元件組合方案的服務，是否可以向客戶收取維護費、諮詢費等等其他費用，而不會觸犯到GPL-2.0的相關規範？
可以的！所有的自由開源軟體專案都可以拿來做商業利用，前提是遵守其個別的授權義務，其實、以GPL-2.0釋出Nagios Core時，NAGIOS公司也是有兼提供商業收費的諮詢服務的，在右列頁面：
www.nagios.com/products/nagioscore，下緣Pricing的部份出現這樣的文字：Nagios Core is available free of charge to organizations that do not require professional support services. For organizations that prefer or are required to obtain professional support, commercial support plans are available starting at $2,495 USD per year.這表示、Nagios Core可以免費被下載取得，但此時NAGIOS公司也不會提供任何的專業服務，所以如果任何組織要以GPL-2.0的方式取得Nagios Core，又想得到NAGIOS公司原廠的技術諮詢服務的話，NAGIOS公司也可以提供這樣的商業諮詢服務，原則上以一年2,495美元為收費計價的標準。這樣的例子就是說，NAGIOS公司本身也有利用「GPL免費釋出 + 技術諮詢收費」的方式來營利，看到了NAGIOS公司自身的例子，您應該可以感到更安心，事實上、GPL授權的專案、本就是可以拿來做商業利用的，只要您遵守條款其他部份的要求。
不過、額外提醒一點，NAGIOS這家公司特別有聲明保留其「NAGIOS相關商標權利 (trademark)」，在Nagios Core程式源碼根目錄下的LEGAL檔裡明示右列的文字：Nagios and the Nagios logo are trademarks, servicemarks, registered trademarks or registered servicemarks owned by Nagios Enterprises, LLC. All other trademarks, servicemarks, registered trademarks, and registered servicemarks are the property of their respective owner(s).而在其官方網站右列頁面：
www.nagios.com/legal/trademarks/，也一再強調trademark的另行授權政策，甚至、其與一家德國公司NETWAYS亦有過商標權方面的授權糾紛，最後在社群動員的影響下，使得這家德國公司認錯讓步 (
www.nagios.com/news/846-victory-in-nagios-trademark-case-shows-power-of-community)。
簡要來說就是、採用GPL-2.0授權的Nagios Core，或其他GPL授權的Cacti、MRTG、Munin、OpenNMS方案來做商業服務，是可以的、但若是有散布GPL-2.0授權的程式碼，則須肩負同時或是嗣後提供程式源碼的義務，若沒有此類程式碼的散布行為，便無此義務。此外、在商業宣傳上，不能使用NAGIOS或Cacti、MRTG、Munin、OpenNMS已註冊的相關商標來進行產品推銷，僅能以「事實描述的角度」，簡要說明此一整合方案是建置在開源專案Nagios Core的運作基礎上，而不能在文句與廣宣上使用到「NagiosⓇ」與其特繪的圖示logo。
約略的法律關係是這樣，GPL授權的元件在應用上是可以進行商業收費的，前提只是收費名目不能是著作權與專利權授權金(royalty)，並且只要一散布了binary code，就必須同時或是嗣後提供Source Code給後手，除此之外，服務費用、建置費用、諮詢費用、維護費用…等等這些名目，都是可以進行收取的。
希望這些資訊對您有所幫助，後續若有疑問歡迎再接續討論。
敬祝 順心健康、新春如意
20140218 11:55 LUCIEN C.H. LIN
Favoured: 0
