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