嗨~ 各位大家好~
想請教一下,
(1)若我自己寫了一個shared library(.so檔), 以動態連結的方式跟GPL software連結在一起,
這樣我寫的shared library也會受GPL限制對吧, 如果我又有一個自己寫的proprietaty software用到該shared library, 這樣也會使這個proprietaty software受到GPL限制嗎?

(2)另外在前述的情況下, 若讓GPL software以fork或exec的方式去呼叫proprietaty software,並等待其回傳結果,也也會使這個proprietaty software受到GPL限制嗎?

(3)若我在(1)的shared library放以下的宣告,可以使得(1)裡的proprietaty software不受到GPL限制嗎?或者需要修改什麼比較符合需求?
請各位不吝指教, 謝謝~

/*
* Copyright (C) 2012, XXX. All Rights Reserved.
*
* Permission to use, copy, modify, and/or distribute this software for any
* purpose with or without fee is hereby granted, provided that the above
* copyright notice and this permission notice appear in all copies.
*
* THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
* WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
* SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
* OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
* CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
*/

Hi Kurapika,

首先破題、先贅述一個核心觀念，那就是 GPL 授權拘束性發動前提在於個別元件被歸類於 GPL 元件的「衍生作品 (derivative work)」，而動態連結／靜態連結 (dynamic link/static link) 都是一個慣用且較通俗的說法，然而其並不是被嚴格定義的法律或技術用語，透過動態／靜態的概念我們可以看出一個「大概」的原則，但是實際細節判斷還是要看該 GPL 與互動元件之間的「衍生性」與「依賴性」。

進一步的相關資訊，可參照拙著「GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍」：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01，以及之前法政論壇上相關討論串的內容：https://www.openfoundry.org/tw/forum?func=view&id=735&catid=8#735。

那麼、接下來就您提出來的問題做簡單的探討，舉例上、把 GPL 授權的元件稱為 A，shared library 稱為 B，其他的proprietary授權的程式元件稱為 C 與 D。

1、若自行撰寫了一個 shared library 形式的 .so 檔，此 .so 檔是以動態連結的方式與 GPL 授權的元件進行互動，這樣的話該 shared library 在後續散布時，也會受到 GPL 的授權拘束、一併使用 GPL 來授權嗎？如果是這樣，那麼其他私有軟體 (proprietary software) 若也與此 shared library 有互動關係，那麼這些私有軟體也會一併受到 GPL 的授權拘束嗎？

關鍵點在於該 .so 檔與 GPL 授權元件之間的存依關係為何。如果該 .so 檔完全依照 GPL 授權元件的運作結構與資料層級來撰寫，那便很容易被判定為 GPL 授權元件的衍生著作，而在後續散布上必須跟著遵循 GPL 的授權規則，但若該 .so 是依照一般標準資料分類的方式撰寫，其與 GPL 授權元件的互動關係就是單純的提供資料，並且也可以被其他非 GPL 授權的元件呼叫來提供資料，則該與 GPL 元件動態互動的 .so 檔，便有機會主張其為獨立的函式庫檔案，而可以不受到 GPL 授權拘束性所及。

簡要來說、A 與 B 之間的拘束性，要視 B 與 A 之間的衍生關係與依賴程度，如果 B 並非參照 A 的程式層級架構來進行撰寫的，而只是單純讓 A 呼叫來提供數據，則 B 並不必然受到 A 的授權拘束，而倘若 B 不受到授權拘束，自然與 B 互動的 C 和 D，也不受到授權拘束。

然而、若是 B 就是參照並依據 A 的軟體架構與資料層級來撰寫而成的，那麼通說認為 B 便為 A 的衍生程式，而必須同受 GPL 授權的拘束，在這樣的情況下、C 與 D 是否同受拘束，一樣要個別來看 B 與 C、B 與 D 之間的衍生關係與依賴關係，如果 C 與 D 都是單純動態性的呼叫 B 來取得資料，並且亦非參照 B 的資料層級來撰寫的，那麼 C 與 D 有機會主張因獨立性而可以自主授權方式，而若不然、則 C 與 D 便同受 GPL 授權的拘束，而得在散布時一併依 GPL 授權的方式提供程式源碼。

2、在上述的情況下, 若該 GPL 授權元件也會以 fork 或 exec 的方式去呼叫私有軟體，並等待私有軟體回傳結果，這樣的互動結構、也會使這些私有軟體受到 GPL 的授權拘束嗎？

原則上不會，這部份的見解可以參考wikipedia上右列整理：https://en.wikipedia.org/wiki/GNU_General_Public_License#Communicating_and_bundling_with_non-GPL_programs

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.

也就是說、從 GNU 計畫的觀點來看，如果是兩個獨立程式之間的資訊交換，並不會因為這樣的互動關係就啟動 GPL 授權元件的拘束性，重點還是回歸兩個元件之間的衍生關係與依賴性，所以一般來說透過 pipe, socket，或是命令列的方式來互動，基本上兩個元件彼此是獨立的，然而、部份惡意規避的案例則不適用這樣的原則規定。所以說、透過 fork 或 exec 等命令使 GPL 授權元件與私有軟體元件產生互動，原則上是不會開啟這個授權拘束性的，除非、該私有軟體元件本就是參照 GPL 授權元件的程式架構與資料層級來寫就的，只是故意設計上讓 GPL 元件僅能透過 fork 或 exec 的方式與其互動，這樣的狀況、就會被很多 GPL 授權元件的著作權利人認定為惡意規避，而引發後續的侵權爭議。

3、若是以 BSD-like 的授權方式釋出前述的 shared library，那麼問題1 裡面的私有軟體是不是就可以不受到 GPL 的授權拘束限制？或是實務上有其他方式可以達到這個目標嗎？

實務上不乏這樣的案例，這細部可以分成兩個層面來說：(1)如果該 shared library 單純以 BSD License 或其他 BSD-like License 釋出，則一般爭議不大，因為 BSD 授權的元件，在再行散布時，本就可以由散布者改以 GPL-2.0 或 GPL-3.0 授權後再釋出，故實務上甚少爭議；(2)但如果該 shared library 雖以 BSD License 或其他 BSD-like License 釋出，或者是 Weak Copyleft 的 LGPL-2.1 或 LGPL-3.0，但透過此函式庫中隔的私有軟體卻沒有採自由開源軟體授權的方式釋出，則實務上衍生的爭議會較大。以現況來論、Google Android 的中隔層就是採行這樣的模式，A 程式為 GPL-2.0 授權的 Linux Kernel、B 函式庫為以BSD、MIT、LGPL-2.1，與Apache License組成的中隔層，其上為私有軟體授權的各式應用程式 C 與 D。然而、Google 要主張中隔層的「獨立性」與「非衍生性」，其實花了很大的氣力和功夫，並且也做了很多中隔優化的工作。實務上常見到的軟體社群說法為，如果 A 程式 5000 行程式碼，而中隔函式庫約 2000 行程式碼，則這樣的中隔 GPL 授權拘束性的機制雖不滿意，但勉強接受，但若 A 程式 5000 行程式碼，而中隔函式庫約 100 行程式碼，則這樣的中隔機制便幾乎會被直接認定為惡意規避，而引發後續的侵權爭議。不過、上述這是一個非常粗略的說法，判定程式元件間的衍生關係，實務上除了量的比較、還有質的分析，不過就是提出在這裡供您了解一個大致的說法。

希望上述資訊對您有所幫助，後續有任何問題歡迎接續討論。



20120707 1355 LUCIEN C.H. LIN

再繼續問幾個問題喔, 謝謝~

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應該不用釋出程式碼了吧?


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 softwareu要釋出程式碼的可能性很大嗎?



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

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