依據林誠夏顧問的大作，｢GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍｣ ( www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02)，動態連結的Linux Kernel Module要進入最後一階段的判斷：GPL 授權元件是否在專案中扮演重要的角色。多數的Kernel Module都有使用Linux Kernel提供的API (memory management, process management, or io processing等等)，會算是符合"GPL 授權元件在專案中扮演重要的角色"嗎?

Kernel Module多是增強Linux Kernel的功能，像是增加對硬體的支援，增加一種檔案系統，或是增加一種演算法，本身有獨立性，但卻又是附屬於Kernel的部分，到底如何判定其獨立性或衍生性？是否過去有案例可參考？

底下複製自en.wikipedia.org/wiki/GNU_General_Public_License，關於獨立性的說明，以供參考：

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).

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.

依上述紅字部分定義，Kernel Module是否可能落入與Kernel相依性過高，而不被視為"獨立"？

感謝解惑!!

Hi paulchu,

「大作」兩個字愧不敢當，希望對大家了解這些議題有所幫助就是了。

你所引述的wiki條目說的很到位：「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.」確實很多自由開源專案的開發者，是用這樣的態度來解釋「原生程式」與「衍生程式」的關係。

而如果你詢問的對象，直接指的就是一般所謂Linux Kernel下「dynamically loaded kernel modules」的話，那麼依照Richard Stallman與Linus Torvalds的看法，原則上都必須受到GPL-2.0授權條款的拘束，而必須在釋出時提供此一模組的相關程式源碼。

直接可參考的文件便是我在「GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）」一文末，所提供的第一篇參考文件：https://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

在這個討論串的內容裡，Linus Torvalds就他個人的立場，表達了相關的重要態度，而這些態度也被其他不少的Linux Kernel開發者所依循著。

以下綱要式的分析這個討論串的相關內容（Linus Torvalds對於Linux Kernel Module在授權拘束性方面的觀點）：

1、只要這個Module是針對Linux Kernel在做設計，並且在設計架構與互動關係上有緊密關聯的話，那這個Module就是Linux Kernel的衍生著作，而在後續散布上、就必須依照GPL-2.0的授權規定一併提供該Module的程式源碼。這樣的解讀觀點來自Linus Torvalds對美國著作權法對衍生著作(derivative work)相關定義，Torvalds並特別表示、這樣的認知並非GPL條款的額外規定，而是他認為衍生著作本來就是這樣定義的。

####

* anything that was written with Linux in mind (whether it then also works on other operating systems or not) is clearly partially a derived work.
* anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.

####

2、有幾個例外狀況，Torvalds認為是可以個案式的認定該Module不是Linux Kernel的衍生著作，例如：A、該Module先於Linux Kernel之前就存在(the Andrew Filesystem, AFS)，或是B、本來是針對其他作業環境來寫就(NVIDIA driver)，之後為了應用上的方便，才porting到Linux Kernel上成為Kernel Module。

####

A、It would be rather preposterous to call the Andrew FileSystem a "derived work" of Linux, for example, so I think it's perfectly OK to have a AFS module, for example.

B、In contrast, these days it would be hard to argue that a new driver or filesystem was developed without any thought of Linux. I think the NVidia people can probably reasonably honestly say that the code they ported had no Linux origin. But quite frankly, I'd be less inclined to believe that for some other projects out there.

####

3、但是要主張例外性的除外，Linus Torvalds認為這部份的主張就要釋出non-GPL kernel module的廠商來說理與闡明了。

####

There is nothing in the kernel license that allows modules to be non-GPLd.

The only thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is not protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived.

####

希望上述的資訊有助於你釐清這個議題！



20120113 1435 LUCIEN C.H. LIN

感謝您這麼清楚的說明！

這麼說來，只要能證明我的軟體曾是獨立於Linux而存在與運作(或是在別的平台上存在與運作)，並不是專為Linux而設計的，在當我將它porting進Linux kernel後，就可以不用GPL。

又或者，如你文章所述，類似Android的做法，先建立一個middleware與Linux kernel銜接，設計自己的程式時，就針對該middleware去設計程式，透過該middleware去存取kernel內的資源，而不要直接使用linux kernel內的任何API，避免落入communication are intimate enough, exchanging complex internal data structures，就也可明白的規避GPL的要求。

我另外注意到這篇文章：tldp.org/HOWTO/Module-HOWTO/copyright.html，也有很詳盡的說明，其中有一段：But if you need to make a practical decision, consider that there have been well-known binary LKMs (drivers for Nvidia video adapters seem to be the most famous) for years and no one has sued for copyright infringement. Also, Linus Torvalds, influential for reasons other than legal, has said binary-only LKMs are OK with him.似乎是告訴大家，binary-only的kernel module其實也不會怎樣。

這裡有另一篇：Legal Risks of Open Source – GPL/Linux Loadable Kernel Modules (sourceauditor.com/blog/legal-risks-of-open-source-gpllinux-loadable-kernel-modules/)。其中提到：the commercial software developer has to accept the strong possibility that their LKMs will need to be open sourced under GPL。也就是說：到時候上法院就知道了。

真是有趣的議題！

Hi paulchu,

其實這個主題在自由開源領域裡就是大家都詳知的灰色地帶(gray area)，雖然大家都知道，但短期之內因為還是沒有任何一個司法判決，所以討論的文章有很多，但實際的判準還是有很多不同的標準。

不過我相信隨著商業化的進程愈來愈久，再加上各個推動組織裡不斷的對話，漸漸會有共識與公定標準產生的。



敬祝 順心、健康

20120116 1715 LUCIEN C.H. LIN