最近又重看了一次GPL3，才想起來在第10條的地方就有能不能徵收授權金方面的敘述，

再轉貼給你作為參考。

當然、3版GPL的普及率目前還比不上2版，

而這段明著禁止徵收royalty的文字也是到了3版才說的那麼明白，

但這解釋了自由軟體基金會在撰寫GPL系列授權條款的基本定向，

確實是依著拑制傳統授權金名目及利用方式的路子來走。

———-

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

除GPL3授權條款本文及其第七條容許的六項「額外添附條款」之外，任何散布者不得於GPL3程式的傳遞過程內，對其後手增加原條款所無的額外限制。舉例來說、任何散布者不得以GPL3授權程式向其後手收受「授權費用」、「權利金」、或是任何依授權名目收求的同類型金額；除此之外、散布GPL3程式者，亦不能依同一程式向其他依GPL3收受此程式的其他使用者，提出各類型的專利侵權訴訟(包括本訴、反訴、附帶訴訟皆不可)。

好在後來無大礙，但因為爸爸三根肋骨有損傷，目前也是需要長期復健。

希望大家、大家的家人以及朋友，都能夠健健康康的。

ant

以下的論述是依GPL文義及多數Linux Kernel開發者歷來的討論觀點，

這表示原則上多數意見是如此，

但個別的獨立Module或是程式，

可能還是要特別去考量該作者對GPL授權拘束性(License Inheritance)的解讀。

1、個別程式與Linux Kernel Module是靜態連結關係(Static Link)，並隨同Linux Kernel併行釋出，則此程式受到GPL授權條款的拘束，合併散布後需一併提供該程式的程式源碼(Source Code)。

2、個別程式與Linux Kernel Module是動態連結關係(Dynamic Link)，只有在特定功能呼叫上才會開啟這個連結關係，那是GPL授權拘束性的「灰色地帶」，一般來說如果該程式還是隨同Linux Kernel併行釋出，則此程式還是有可能被解讀受到GPL授權條款的拘束，被要求需一併提供程式源碼(Source Code)，故一般建議是、既然為動態連結關係，可以不要將該程式與Linux Kernel合併散布，而採嗣後讓使用者自行下載安裝的方式，來杜絕爭議性。

3、然而、該個別程式與Linux Kernel個別釋出、嗣後結合的動作，不可透過機械化的自動方式來進行，該個別程式與Linux Kernel的結合，要由下載者或是嗣後安裝者，並了解到「結合後整個產品會全部拘束在GPL授權拘束之下」後自行決定要不要結合。因為若是嗣後的結合動作是全自動的，該程式還是會被認定與Linux Kernel是「一個合併的散布行為」，而讓整個產品都受到GPL授權拘束性的影響。

所以、針對你的問題來做回覆：

1、修改GPL2授權的Linux Kernel Module，讓它和自己開發的Module連結並合併散布，那自行開發的Module是會被要求需提供程式源碼出來的。

2、若是單獨釋出自己的Module，讓使用者自行編譯自Linux Kernel裡，原則上就處於灰色地帶，有人認為可以不受到GPL授權拘束性的影響，有人認為是一種實質的規避，但實務上來說、這個自行編譯的動作不能「全自動化」，要讓編譯者了解「該程式與Linux Kernel編譯結合後出了任何問題，不應回報給Linux Kernel的程式開發團隊」，因為該bug的產生牽涉到未提供源碼的Module，不是Linux Kernel開發者願意去背書、處理的(Linus Trovolds本人特別強調這一點)。

希望以上的回覆對你有所幫助。

後續還有問題歡迎接續討論。

20100225 Lucien C.H. Lin