Hi CeciliaWu,
一般來說在論壇發問會得到較快的解答，因為回覆的內容可以讓大家都瀏覽得到，且這樣的方式也較能夠引發進一步的討論，故一個不成文的時間線，我在看到論壇發文之後三天之內會給一個簡要的回覆，不過有時人在外地進行差旅，或適逢假期在外，可能回覆的速度就緩些，還請能夠見諒。
關於您所提出來的問題，涉及的主要是以"avahi"這個開源專案為核心利用對象，所轉化出來的衍生關係問題，那麼，我先略述一下自己對"avahi"專案在授權分析上的認識：
1、avahi專案程式碼確實是以LGPL-2.1向外授權釋出，相關證明，可參照其最新穩定版本0.6.31版本(
https://avahi.org/download/avahi-0.6.31.tar.gz)根目錄下"LICENSE"檔案的內容。
2、透過連結或相類似的API(Application Program Interface)呼叫LGPL-2.1授權函式庫來取得資訊的單純利用行為，並不會讓與其互動的程式，落入到衍生著作的範圍內，從而便可不受到LGPL-2.1函式庫的授權拘束。關於LGPL授權拘束性的進一步說明，可參閱拙撰「稍稍鬆綁的堅持－LGPL」：
https://www.openfoundry.org/tw/legal-column-list/519--lgpl，以及「更為彈性中庸的 LGPL-3.0」一文：
https://www.openfoundry.org/tw/legal-column-list/1166--lgpl3
3、以不精確、但最簡明的方式來說明LGPL-2.1授權函式庫的授權拘束性，就是：透過LGPL-2.1授權函式庫預設介面或流程，來對函式庫程式進行呼叫以取得資訊，此種互動關係之下，呼叫元件並不會被視為LGPL-2.1函式庫的衍生程式，從而在授權方式上便不受到LGPL-2.1的拘束，更通俗的來說：一般被視為動態連結(dynamic link)的呼叫方式，並不會去啟動LGPL-2.1函式庫的授權拘束性，而被視為靜態連結(static link)的呼叫方式，若能夠述明該元件與LGPL-2.1之間的互動資訊，且此提供給使用者的互動資訊，已能讓使用者嗣後以更新版本的LGPL-2.1授權函式庫，來代換掉原專案裡用的舊版函式庫的話，那麼此種狀況也不會啟動LGPL-2.1函式庫的授權拘束性。
因為，LGPL授權方式相關於GPL，就是一個在授權拘束性上較為寬鬆的Lesser版本，故關於LGPL授權方式的微言大義就是：單純呼叫存取函式庫功能的取用行為，不會開啟其授權拘束性；然而，若是就函式庫本身來撰寫衍生程式，並將此衍生程式內植至LGPL函式庫裡成為其功能的一部份，則新的衍生函式庫，就必須承襲LGPL的授權模式。
----
接著，便以上述表述的資訊為基礎，來回覆您所提出的相關問題：
1、客人打算另外寫一個獨立程式(separate program) XX，會使用我們“modified avahi”，請問XX程式是否落入LGPL的授權適用（而須公開原始碼）嗎？
此一"modified avahi"由於是直接修改LGPL-2.1授權的avahi，故其仍然必須承繼LGPL-2.1的授權模式，而其他程式元件，例如xx，若能證明乃是被獨立撰寫(在不參考avahi層級架構的前提下進行撰寫)，且透過avahi預設的呼叫介面與流程來與其互動，則在授權分析上，xx並不會被視為avahi函式庫的衍生元件，從而在授權方式上，可使用自行律定的商業授權模式，只要這個授權模式不去和LGPL-2.1授權部份的函式庫產生衝突即可。所謂不產生衝突，意指自訂的商業授權模式，不能去妨礙到原本LGPL-2.1授權函式庫依LGPL-2.1授權規則被利用的狀態，例如，LGPL-2.1條款內已明言：與其互動的元件授權，即使不依LGPL-2.1向外授權，亦不能在自訂的授權規則裡禁止收受程式的後手進行還原工程的研究。(
the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications)
2、客人打算另外寫一個獨立程式(separate program) YY，該YY程式會communicate with XX via Linux messages，請問YY程式是否落入LGPL的授權適用？
此處指的是YY元件會與XX元件就Linux相關資訊來做分享和交換，一般來說XX元件若透過avahi的既成介面(interface)來與avahi溝通，或XX元件與avahi的互動關係資訊，已經適切的提供出來，讓使用者可以在更換avahi版本之後，依互動資訊重建avahi與XX元件之間的互動關係時，則XX元件之於avahi，便為獨立元件，而不受avahi-LGPL-2.1授權拘束的限制；在這種狀況下，XX元件既已為獨立元件，則與其互動的YY元件，便更不受到LGPL-2.1授權模式的影響。
然而！有待釐清的就是，此處提到YY元件與XX元件之間，會就Linux相關資訊來做分享與互動，則其實更該注意的是，YY元件、XX元件兩者與Linux Kernel之間的互動關係為何？因Linux Kernel是採授權拘束特性較諸LGPL-2.1更嚴謹的GPL-2.0來授權，所以若YY元件、XX元件兩者其一，或皆會直接與Linux Kernel產生功能互動，則其是否會被視為Linux Kernel的直接衍生元件，就還要看互動上的細節而定；但若是能確認YY元件僅會與XX元件互動，而XX元件僅會透過avahi與Linux Kernel互動，此兩元件皆不會直接與Linux Kernel產生互動的話，則YY元件原則上，便不致落入LGPL-2.1的授權拘束範圍。
3、客人打算另外寫一個獨立程式(separate program) ZZ，該ZZ程式會communicate with XX via reading and writing to a same file or shared memory。請問ZZ程式是否落入LGPL的授權適用?
若是XX元件在第一個問題能被判定為真正獨立的程式，則XX本身已不受LGPL-2.1的授權拘束，則ZZ元件雖與其會同時對同一檔案進行讀取與寫入，或運作是被併入同一個記憶體區段來執行，亦不會讓ZZ元件被視為avahi的衍生元件；然而，若是XX元件是直接參考avahi的程式架構來撰寫(Work based on the original LGPL-2.1 work)，且運作上直接內嵌到avahi的架構裡，而無法透過中介透明的API，則XX元件可能便會被視為avahi衍生元件，而必須同依LGPL-2.1的授權方式來對外提供，此時，ZZ元件如果與XX元件同跑在同一個記憶體區段，或有直接承襲的呼叫架構時，便可能會讓ZZ元件也一併被判讀為LGPL-2.1授權的衍生元件。
進一步的相關說明，也許您可以參照一下，GNU計畫對於程式元件衍生關係的常見問答：
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
我將關鍵字句中譯如下，亦提供在此讓您做個簡要的參考：
https://lucien.cc/lucien/doku/doku.php?id=notes_and_translations:frequently_asked_questions_about_the_gnu_licenses
####
所謂的「聚合著作」指的是許多獨立運作的程式，在散布時被儲放在同一個散布媒介，如CD光碟片上一同散布。GPL授權條款容許GPL程式能夠與其他程式，集結為聚合著作後合併散布，即使聚合著作裡其他的程式並非自由軟體，或者在授權狀態上是與GPL不相容亦可。此種作法唯一要注意的地方，就是整個聚合著作的授權方式，並不能去干涉聚合著作裡個別程式所本有的授權規則。
關於程式與程式間的聚合關係，究竟是二個獨立程式被合併儲放，或者是一個程式被切割為二個部份後儲放，這是一個法律問題，也就是說、有權做最後判定的是訴訟發生時的承審法官。不過、原則上，這樣的問題可以從二個層面來進行判定，一是程式與程式間的溝通機制的方式(例如：究竟是以exec、 pipes、rpc，或是呼叫function calls後在同一段共享記憶體區段執行的種種不同方式)，第二則是程式與程式間溝通語彙的內容(究竟這二個程式運作時交換的是哪類別的資料)。
所以、如果不同的程式模組已經被結合在同一個可執行檔中去運作，那此種結合狀態很明確的就是兩個程式被結合為一個單一程式。而如果是不同的程式模組，但在設計上預設會透過連結的方式，呼叫彼此到同一段共享記憶體去運作，那也幾乎可以表示這兩個模組其實就是一個單一程式的二個部份。
以比較的方式來解說，兩個獨立的程式常會透過pipes、sockets，或是下command-line的方式來結合運作。所以如果二個程式模組之間的構通機制是透過pipes、sockets，或是command line的方式，那這二個模組之間的結合關係，通常會被判定就是聚合著作而非程式彼此間的修改著作。然而、如果這二個程式模組在資訊交換上有著相同結構的語彙邏輯，則就算彼此是透過pipes、sockets，或是command line的方式來溝通，但因為彼此交換的資訊具有層級上的相同性，足證這樣的結合運作關係密不可分，故也有可能例外的被認定是同一個軟體程式的二部份。
####
4、又，如果客人決定不自己寫XX,YY,ZZ程式，而交由我們撰寫，該XX,YY,ZZ程式和我們修改LGPL寫出的“modified avahi”的互動模式同上，請問適用LGPL與否的結果會因為該XX,YY,ZZ程式是由我們寫或客人寫而不同嗎？
原則上，在法律授權的衍生關係上，不會有什麼不同和差異。
5、由於客人並不想把source open，因此擔心因為我們使用了LGPL，其販售等同於distribution，故整個程式都需要公開。請問LGPL v2.1的第六條例外我們有適用餘地嗎？如果有，是否就等於無須受LGPL v2.1授權條款的公開原始碼要求？
LGPL-2.1第6條的例外關係，當然有適用的餘地，因為一般實務上許多自由開源軟體社群，看待LGPL-2.1授權拘束性的議題時，確實要比GPL-2.0寬鬆許多，畢竟，LGPL-2.1之於GPL-2.0，本就是一個刻意在授權拘束性上放鬆的版本，故如上所述，只要能夠：1、透過連結或相類似的既定API去呼叫LGPL-2.1授權函式庫，來單純利用LGPL-2.1授權的函式庫；2、提供其他元件與LGPL-2.1授權函式庫在互動上的必要資訊，此部份資訊充足到使用者如具相當的軟體工程實作能力，便可將更新版本的avahi置入到您所販售的軟體專案裡，達到此一標準，更能大為降低該商販專案裡其他商用元件的授權妥適性。
而其實，avahi原則上是搭配Linux Kernel來進行應用，Linux Kernel本身是以授權更為嚴謹的GPL-2.0向外授權，以Samsung的開源釋出網站為例：
opensource.samsung.com/，其在販售Embedded Linux智慧型手機時，亦有透過網路提供Linux Kernel相關的程式源碼，所以說，販售等同開源元件的散布這句話是沒有錯，而散布了開源元件之後，依授權條款本就有該提供程式源碼的範圍，但細節上應該是具體的去釐清該提供的源碼範圍，並不是說整個軟體專案的程式源碼都被迫一定要提供出來，但本來係屬GPL、LGPL的部份，以及此部份直接衍生而產生授權承繼(license inheritance)關係的部份，方為後續商販之時，須應消費者需求而提供出來的部份。
希望上述的資訊對您有所幫助，如再有相關疑問，歡迎您接續討論。
20140224 15:05 LUCIEN C.H. LIN
Favoured: 0
。
