您好:
請問android的授權模式中, 中間層的apache license就能完全避免GPLvX的感染嗎?
所以只要有一層MIT/BSD/LGPL/Apache license的wrapper在被使用的GPLvX之間
就能避免被GPLvX感染嗎?
還是要存有像user space/ kernel space的非直接關係才可以呢?

hi, mexwell,

這個問題，我們先從 GPL（條文本身）的規定來看，再從 Linux Foundation（著作權人）的意思來看。

簡單地說，依 GPL 的規定，只要一支程式中有一部分的程式碼是取自（合併自、改作自、連結自）GPL 程式者，就必須整支程式都要／也只可以用 GPL 來釋出給公眾，除非我有經過原 GPL 程式作者另外的授權，才可以例外地不依 GPL 的規定來走。

接著，Android 雖然的確有用到屬於 GPL v2 授權的 Linux kernel，但 Linux Foundation 創辦人暨精神領袖 Linus Torvalds 給出來的條件是：如果是在 user space 的部分，不會被 kernel space 部分的 GPL 所影響，但如果是在 kernel space 的（有用到 system calls），那歹勢，還是有 GPL 的感染性。（註一）

其實很明顯的是，Linux Foundation 的這個解釋已經超出了 GPL 的文義解釋的範圍，也就是說，它的授權規定雖然是 GPL，但因為他是著作權人，他也可以宣告，他的程式碼的 GPL 感染性僅及於 kernel space。總之，在法律上是可以這樣做的。

所以，回到你的問題，判斷標準的重點在於，它是屬於 user space 還是 kernel space。如果是在 kernel space（也就是有用到 system calls 的話），不管怎麼包，還是屬於 GPL 感染的範疇。（註二）

（註一）參見：[linux/kernel/git/torvalds/linux-2.6.git] / COPYING，摘錄如下：
1
2 NOTE! This copyright does *not* cover user programs that use kernel
3 services by normal system calls - this is merely considered normal use
4 of the kernel, and does *not* fall under the heading of "derived work".
5 Also note that the GPL below is copyrighted by the Free Software
6 Foundation, but the instance of code that it refers to (the Linux
7 kernel) is copyrighted by me and others who actually wrote it.
8
9 Also note that the only valid version of the GPL as far as the kernel
10 is concerned is _this_ particular version of the license (ie v2, not
11 v2.2 or v3.x or whatever), unless explicitly otherwise stated.
12
13 Linus Torvalds

（註二）相關文章參考：葛冬梅，Android 的區隔 GPL 感染機制。其中也有說明，我以上的見解可能不見得一定是大家的共識，因為還沒有法院判決確定。所以目前仍然可能是「一個 GPL，各自表述」的情況。

您好:
感謝您的回答

看起來linux kernel應該只是個著作權人同意的特例是吧?
所以一般來說,
如果我的私有程式(不管是user space/ kernel space)
有用到GPLvX的元件(不管是user space/ kernel space)
除非是著作權人同意 or 符合宣告的exception條款外
基本上都會被GPLvX感染嗎?
如果我的私有程式是具有「獨立性(Separate and independent work)」的程式,
跟GPLvX的元件沒有「必然的依賴性」, 結合密度及依存關係低的呢?

另外還有個關於toolchain的疑惑
因為GNU的toolchain非常知名且廣為運用(ex: gcc or bison)
是不是所有會被GNU toolchain編譯到的程式碼
都會被GPLvX感染嗎?
還是要case by case, 看程式碼是用到什麼toolchain裡的元件,其license為何呢?

Hi, mexwell,

是的，Linux kernel 的授權情況的確是一個特例。GPL 內文並沒有這樣區分。

如果你的私有程式有用到 GPL 的元件，也就是你有重製他的程式碼（超過十行的話），這時你重製的動作就代表了你已經同意 GPL 的規定（因為，如果你不希望你的程式適用 GPL 的話，你就不能夠抄他的程式碼；所以有抄就會推定會同意接受 GPL）。當然，我相信你也讀了條款，其中有說如果是分隔且獨立的作品，也就是在法律上不算是原程式的衍生著作的話，就可以與 GPL 脫勾。但實務上最直觀也最常用的判斷標準是到底有沒有內含 GPL code，因為這個最客觀，也未涉及法律層面的判斷（法律層面的判斷是法院審判時才會做的，在進入訴訟前很難先確定到底算不算獨立作品）。

你說，若你的私有程式有獨立性，並且與 GPL 元件沒有必然依賴性，就上面的標準來看，第一步還是先看有沒有用到 GPL code，若無則肯定與 GPL 無關；若有，會被先當成你必須適用 GPL，原則上是你必須證明你的程式並非屬於原 GPL 程式的衍生作品。

當然，也會有一些牽涉到事實層面的影響。例如，原 GPL 元件作者對於 GPL 解釋的態度如何？他對於你的程式是否具有獨立性的看法其實很關鍵，如果他確實認為你利用到他的元件是很低程度的利用，以致於無 GPL 的感染性的話，那你自然就可以不依 GPL 授權。


另外，你第二段的問題，例如 GCC 好了，在 compile 的過程中當然會多少用到原以 GPL 授權的 code，我個人的看法是，這類工具只是幫助人去編譯，你的目的不是取用、改作他的程式碼、法律上也不容易把你 compile 出來的程式認定為 GCC 的衍生作品，所以我認為在單純利用 GCC（而非去改 GCC 的 code 或 debug）做編譯的情況下，是不會被 GPL 感染的（這裡可能會有不同意見）。

不過無論如何，GCC 及 Bison 都有除外規定了（註一），以防止大家的疑慮。

當然，如果一個 toolchain 並非以 GPL 類的條款進行授權，不論是 BSD、MIT、EPL 及其他授權，原則上都不會有須依其條款強制開放源碼的疑慮。


（註一）參見，曾義峰，自由軟體授權探討: GNU GCC 例外授權。其中列舉了 GCC、Bison 以及 Flex 相關的例外授權文字。

您好:
sorry 我沒有對"用到GPL code"的方式解釋清楚
我想請問的是,正常情況下(非exception) 對GPL程式碼
只是include header, link separate library(.so)
然後呼叫使用GPL程式碼裡的function
這樣也會受GPL感染嗎?
是不是要依它們之間的結合密度及依存關係而定呢?
如果這種情況下不會感染,那不是跟LGPL很類似嗎?

另外,之前我們討論的CASE大多為私有程式使用到GPL程式碼
現在我想請問 反過來使用的過程中(GPL/LGPL程式碼用到私有程式的話)
私有程式的部份是都不受感染嗎?
如:
1.用私有toolchain re-compile GPL/LGPL程式碼
2.用GPL/LGPL程式碼,include 私有程式的header, link到私有的程式

Hi, mexwell,

就你的第一個問題，GPL 所謂的「用到」是指：1. 修改該程式碼（改善功能或 debug 之類的）；2. 將 GPL code 與其他 code 合併；3. link GPL code 到自己的 code 等等。如果你是「include header, link separate library (.so) which is GPL'ed」，那麼這個我的解讀是一個 dynamic link；不論是 static or dynamic link，在 GPL 中都算是有用到的，所以就必須接受 GPL 的授權拘束，會受到 GPL 感染。也就是說，這個與結合密切及依存關係沒有太大的關係，只要存在前述的利用關係，就會有 GPL 的適用。

LGPL 會問世，就是基於上述 GPL 可能不夠具有彈性的特性而來的；所以二者當然是不一樣的。當初 rms 及 GPL 的支持者發現大家都不用 GPL 的 library，才了解到是因為 GPL 的影響範圍太廣，大家不見得願意接受 link library = GPL 這件事。而 library 的特性就是要給人家來 link 的，GPL 反而使得它們被利用的程度降低了；為了配合 library 的特性，於是 FSF 就發行了另一種授權模式，即 LGPL（註一）。LGPL 的特性就在於，它限制了授權拘束性的範圍，需要 open 的部分不像 GPL 要求整支程式所有 code 都得 open 出來，而是以 library 本身為界限：如果我們單純地用到這個 LGPL 的 library，我們主程式並無義務要改用 LGPL 來進行 open；但如果我們去修改了該 library 本身的話，我們還是要把修改開發的成果依 LGPL 釋出給拿到這支程式的人。所以說，GPL 與 LGPL 在授權拘束性的範圍是不同的。

另外，第二段的問題，我的回覆如下：

1. 如果用私有 toolchain re-compile GPL/LGPL 程式碼，編譯出來的成果一樣要遵循原來的授權方式。原因是：compile 的過程只是一個機械性質的改作，原 code 的授權狀態不會因為這樣的改作而有所變化；也就是說，這個情況下不會因為 toolchain 是不是自由軟體，而影響到 recompile 結果的授權狀態。依這個邏輯，這種情況不只有 GPL/LGPL 會發生，例如我去 compile MPL/EPL 的程式碼，compile 出來的結果一樣會是以 MPL/EPL 授權的。

2. 今天這種情況是反過來看，主程式是 GPL/LGPL，而 include 私有程式的 header，link 到私有程式；在主程式是 GPL 的狀態下，我仍然認為是會受到 GPL 感染，原因分析如下（註二）：

講遠一點，GPL 要求跟他有關聯、有用到的 code 都必須 open 的原因是為了讓程式設計師可以拿到完整的 code，在 debug 時才能真正找到問題（如果只 open 一半，則可能 debug 到死都不能確定 bug 是在 open 的那個地方還是在 unopen 的 binary 處）。所以，回過頭來，在你說的情況下，即使是 GPL code include 私有程式的 header，link 到私有程式，對於收受程式的人來說，仍然希望看到全部的 code，也就是說，依 GPL 規定，誰把 code 放進來讓 GPL code 去 link，誰就要把那部分的 code 給 open 出來。

所以這裡牽涉到一個問題：假設我根本就沒有那部分私有程式的 source code，該怎麼辦？

如果我有那部分的 source code，那依 GPL 給出來，至少不會違反到 GPL；但如果那部分的 code 我沒有，我只是拿人家的 binary 來 include/ link 的，那麼，第一點、我根本無力給出那些 code；第二點、別人的 code 忽然就變成 GPL 的，不是很無辜？

我曾經在網路上看過有些意見認為這時這些 code 不應該被 GPL 感染，是由於上述的疑問所致。但事實上，我仍然認為它有 GPL 的適用，是因為我們如果要拿其他 code 與 GPL code 一起運作，我們本來就必須要有這些非 GPL code 的著作權（或授權），才能這麼來用。如果那是別人的 code，我就利用了，這點本來就是會產生侵權的情況，不論我是不是把用拿來用到 GPL code 中；這跟 GPL 的感染性其實並沒有關係。

再來，如果我們真的拿別人的 code 這麼做了，那個別人需不需要依 GPL open source？答案當然是不用。因為 GPL 所要求 open source 的義務人是那個用到 GPL code 的行為人，而不是那個私有程式的著作權所有人。如果我們真的這麼做了，也不會害到別人必須 open source；但因為我們自己也沒有那些 source code，事實上根本給不出來，所以一定會違反 GPL 要求我們要 open source 的規定。因為我們違反了 GPL，所以就等於未依原 GPL 程式作者的意思來利用他的程式，這時會造成侵權的結果；侵權就會產生民事上損害賠償、商品下架以及刑事上非法重製罪的法律風險（如果原著作權人採取法律行動的話，這些是可能發生的後果；至於原著作權人是否有採取法律訴訟的意願，就要視個案情況來判斷了）。


最後，也謝謝你的深入提問，讓我有機會整理一下自己的思緒，把想法寫出來。當然，有任何問題，很歡迎一起繼續討論！


（註一）原來 LGPL 的名字叫做 GNU Library General Public License，這對於 FSF 及 rms 來說只是個權宜之計，其實他們心中還是希望所有 free software 都是用 GPL 來授權的；但大部分的程式設計師看到 LGPL 的「library」這個字眼，就以為他的 library 只能用 LGPL 來授權，或是以為 FSF 提倡要用 LGPL 來授權其 library，這個誤解也違背了 FSF 及 rms 的原意。所以後來他們就把 LGPL 的名稱改為：GNU Lesser General Public License，意思是比 GPL 來的弱一點（lesser）的授權方式，並且僅限使用於 library 及類似於提供 library 功能的程式。

（註二）這裡我不討論 LGPL 的情況是因為，如上所述，LGPL 的範圍就只有在 library 的部分必須 open，所以其實很好判斷是否必須依 LGPL 來 open source code。