Hi,各位好,
"請問一下,如果我自己開發一個module,但是因為某種原因我必須將module與Linux kernel結合在一起,
能不能只釋出該module的assembly code就好,我是用C開發的"
這是某人問我的問題,我自己覺得應該不行,但想不到說服他的理由,請專業的幫忙回答一下
謝謝

Hi Kurapika,

好久不見！

這個問題簡要來說、如果該module與Linux Kernel是merge的結合關係，並且合併散布的話，那依Linux Kernel著作權利人的看法，該module就是Linux Kernel的衍生著作，因為該module若是不與Linux Kernel結合在一起就無法作用，並且實際上的狀況它也是一併散布，那就很難有立場拒絕受到GPL-2.0授權條款的拘束。

我在今年(2012)年初有針對類似的問題做過說明，原貼連結如右：https://www.openfoundry.org/tw/forum?func=view&catid=8&id=735#737

我再將重點贅貼一次如下！

----

如果討論的對象，直接指的就是一般所謂Linux Kernel下「dynamically loaded kernel modules」、或是直接常態連結的module，那麼依照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.

####

大致的狀況是這樣，希望上述的資訊對您有所幫助，有後續的問題歡迎隨時接續討論！



敬祝 順心健康、事事如意

20120531 1055 LUCIEN C.H. LIN

Hi Kurapika,

補充追問一下資料，您原文確實提到「自己開發一個module,但是因為某種原因我必須將module與Linux kernel結合在一起…」

那麼請問這個新開發的module，除了能與Linux Kernel結合運作之外，也可以在其他非Linux Kernel based的作業平台上運作嗎？

如果確實可以、那就要細節再看是不是符合個案式的例外條件了，例如前文所說的：A、該Module先於Linux Kernel之前就存在(the Andrew Filesystem, AFS)，或是B、本來是針對其他作業環境來寫就(NVIDIA driver)，之後為了應用上的方便，才porting到Linux Kernel上成為Kernel Module。

Regards,

20120531 1100 LUCIEN C.H. LIN

謝謝lucien的解釋,
我還有個問題,
如果某人是以C開發軟體,但只想釋出assembly code,
這assembly code其實也是machine-readable source code,
可以這樣來規避GPL嗎,
如果這樣不可行的話,可以麻煩你幫我指出是違反GPL裡的哪一條規定呢?
謝謝

Hi Kurapika,

直接以assembly code為Source Code釋放出去，還是會有引發GPL爭議的風險。

為什麼呢？因為許多社群開發者認為這僅是「技術上的程式源碼(technical)」，而「非GPL定義的程式源碼」：https://developers.slashdot.org/story/11/07/29/1445252/emacs-has-been-violating-the-gpl-since-2009

舉例上、可以從之前討論很熱烈的GNU Emacs來看，David Kastrup這位開發者，在2011年7月27號、透過郵件論壇的方式指出，GNU Emacs從23.1.90版之後，部份的程式源碼是直接透過GNU Bison建立，所以提供的格式並非程式開發者最初編輯的程式源碼。這個問題被舉報出來以後，Richard Stallman隨即回覆，認為此種源碼格式的給法是違反GPL授權條款的，然後用最快的速度敦促開發團隊將最初編輯的程式源碼加進到GNU Emacs更新的版本裡。

這個事件的進一步資訊，可參照曾義峰先生所撰寫的專文，「談 GPL 軟體原始碼定義及瑕疵修復方式－從 GNU Emacs 違反 GPL 授權條款一事說起」：https://www.openfoundry.org/tw/enterprise-application/8629--gpl-gnu-emacs-gpl-

所以、我們從GNU Emacs的案例來看，可以知道對於許多GPL專案程式的開發者來說，他們認知到的程式源碼，是指「GPL定義的程式源碼」，那麼「GPL定義的程式源碼」究竟為何？

GPL-2.0: The source code for a work means the preferred form of the work for making modifications to it.

GPL-3.0: The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

透過上面這二段授權條款的文字，我們可以發現重點在於「the preferred form」，那麼、何謂preferred form？preferred form不是一個精確的技術名詞，反而是具有解釋意涵的「不確定法律概念」。這是一個條款／契約訂立方面常見的技巧，也就是說、透過一些具有解釋內涵的語彙，讓Source Code定義範圍的解釋更具彈性空間，而不是特指某一個技術格式。

自由軟體基金會，向來將「the preferred form」解釋為「原作者或是原修改者，日後自己要再修改這隻程式或是該元件時，所使用的文件格式。」也就是說、如果將這個標準套用到您的問題，那麼多數自由軟體基金會成員的看法會是：「如果該assembly code的作者自己在做該程式的修改時，也會直接目視該machine-readable的Source Code來進行修改，那麼他們就沒有反對意見；反之、如果該assembly code的作者自己後續要進行程式修改時，會透過其他工具組來編修這支程式，那麼釋出時就應該要一併釋出這些工具組相關的資訊，以及必要的編譯腳本。(complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable.)」

所以才會說，直接以assembly code為Source Code釋放出去，還是會有引發GPL爭議的風險。因為有許多的自由開源軟體開發者，認為這樣的格式並非「the preferred form」。那麼、要說這樣的爭議是違反到GPL裡哪一條規定，我認為就是「Source Code定義的相關條款」，例如GPL-2.0第3條第2項，以及GPL-3.0第1條第1項。

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



20120605 1415 LUCIEN C.H. LIN

----

謝謝lucien的解釋,
我還有個問題,
如果某人是以C開發軟體,但只想釋出assembly code,
這assembly code其實也是machine-readable source code,
可以這樣來規避GPL嗎,
如果這樣不可行的話,可以麻煩你幫我指出是違反GPL裡的哪一條規定呢?
謝謝

超級感謝lucien, 讓我對GPL有更進一步的了解呀!