Hi Kurapika,

歡迎討論！只是有時候手上的事情比較忙，若是回覆的速度較慢，還請見諒。

以下簡短回覆您的問題。

1、若是自行撰寫的 shared lib 被宣告為 LGPL，使 GPL software 用 function call 使用該 shared lib，也就是"work that uses the library"的方式，而我所寫的 proprietary software 也利用 function call 使用該 shared lib，且 proprietary software 並不會透過該 shared lib 跟 GPL software 互動，這樣我們所寫的 proprietary software 應該不用釋出程式碼了吧？

對的，這樣的互動方式原則上沒有什麼問題，因為該 Shared Library 可被不同授權方式的程式所呼叫，這些呼叫程式彼此之間也沒有互動關係，不會是彼此的衍生著作，再者，如果只是 function call 或是 command line 方式的呼叫，原則上本就不會啟動 LGPL library 的授權拘束性，而現在這個 LGPL library 又是您自己寫的，所以解讀上的風險性就更低了。

2、若是自行撰寫的 shared lib 被宣告為 LGPL，使 GPL software 用 function call 使用該 shared lib，也就是"work that uses the library"的方式，而我所寫的 proprietary software 也利用 function call 使用該 shared lib，且 proprietary software 並不會透過該 shared lib 跟 GPL software 互動；但 proprietary software 是以 fork 或 exec 的方式呼叫 GPL software，並將一些設定環境的參數傳送給 GPL software，而此 proprietary software 也不用等 GPL software 回傳結果，但這樣的互動也沒有經過中隔層，這樣我所寫的 proprietary software 要釋出程式碼的可能性很大嗎？

訴訟風險目前看來不會很大，但還是要看利用到的是哪一個 GPL 授權專案，來評估引起社群非議的可能性是高還是低。

其實看這個問題原則上可以先略過 shared lib 的層次，因為該 proprietary software 與 GPL software 並沒有透過任何中隔機制來溝通，也就是說，題目可以簡化為「proprietary software 透過 fork 或 exec 的方式呼叫 GPL software，並將一些設定環境的參數傳送給 GPL software，會不會讓這個 proprietary software 受到該 GPL 授權程式的拘束。」

答案是可能會、可能不會，因為這個狀況正是落入 GPL 授權義務性的灰色地帶。

依照 GPL-2.0 的定義，最重要的就是右列這段：If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

之所以說這是核心定義，因為許多 GPL 授權專案的權利人，都是從這段文字進行望文生義，基本上多數的 GPL 專案開發者認知到的擴散規則就是：「個別程式不是衍生自 GPL 程式，則其散布上可以自己選擇授權方式，但若就其程式碼的抄寫狀況、資料分類的層級架構，以及互動緊密性，可以看出必然是衍生自 GPL 授權程式，則該程式在散布上只能依照 GPL 授權條款。」

在WIKIPEDIA有整理出通說的見解，右列的說明也描述出這樣的狀況：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. The FSF thus draws the line between "library" and "other program" via 1) "complexity" and "intimacy" of information exchange, and 2) mechanism (rather than semantics), but resigns that the question is not clear-cut and that in complex situations, case law will need to decide.

從而可以歸納出幾個要點：

(1) 程式元件間透過 pipe、socket、command-line 這種方式來進行互動，原則上兩個元件是彼此獨立，並不能說誰是誰的衍生程式。

(2) 但若是佐證上可以看出兩個元件間在資料架構及資訊交換間高度的合致性，則也可能被認為就是同一個軟體專案的兩部份。

(3) 進一步的標準，還是要經過個案判定才會清楚。

所以，我的看法是，如果您所撰寫的這個 proprietary software 並不是參考此一 GPL software 進行撰寫，而僅是透過 fork、exec 的方式呼叫 GPL software 提供功能，並且該 GPL software 在產品裡的定位，其實必要時也可以改置其他的 proprietary software 或是 Open Source 元件進行取代的話，那引發 GPL 授權爭議的風險性便不大。

3.已經有類似情況的 GPL violation 嗎？請問有案例可以參考嗎? 謝謝~

實際這種互動方式產生訴訟的案子並沒有，因為這屬於灰色地帶，目前訴訟的案子多還是發生在很具體明顯違反 GPL 的狀況。而如果說是社群論壇的討論的話，在 gpl-violations.org 的網路 archive，09年到10年有一些這方面的討論（授權相關：https://lists.gpl-violations.org/pipermail/legal/，技術相關：https://lists.gpl-violations.org/pipermail/tech/），據我所知，因為此種呼叫關係而引發社群朋友或是權利人寄發警告信的例子並不是沒有，多數是在溝通之後以和解收場，收解條件可能包括必要的賠償金，公司允諾以其他元件更換 GPL software，或是定一季、半年不等的時間重新改寫置換掉 GPL 授權的程式碼等等…

所以，還是回歸一點提醒，真的要確認該程式元件與 GPL 授權元件，是否處在一個完全不會引發爭議的互動關係，在授權分析上需要個案上更清楚的資訊，例如該元件功能為何？GPL 程式功能為何？該產品提供消費者的功能有哪些？哪一個 GPL 元件，其網路下載頁面，其支援社群對 GPL 授權條款的解讀態度等等…如果您對這些議題有進一步討論的興趣，但考量到部份資訊也許不適合在公開論壇上進行表述，則可以透過自由軟體鑄造場的連絡信箱 contact@openfoundry.org 來與我聯繫。

希望上述資訊對您有所幫助！



20120720 1145 LUCIEN C.H. LIN