對於GPL，我存在個疑問，如果今天我修改了linux某個module（增加interface），使其跟我自己開發的module（無包含 GPL source）連結在一起，這樣當我發佈這著修改過後的linux module，是否也需要公布我自行開發的source呢？看條文感覺像是要，因為授權會擴及整個產品，除非我單獨釋出自己的module？如果我釋出自己的module與修改過的linux source，交由使用者自行編譯成新的module，而不釋出自己的source，這樣算是違反GPL嗎？懇請解答，謝謝。

P.S.1.該linux module宣告用GPL授權。
2.參照https://whoswho.openfoundry.org/forum.html?func=view&catid=8&id=370
修改後的linux module如果不使用我所定義的function，功能上與原來的module並無差別，亦可以用空的function取代。

Hi goaway0621 ，

以下的論述是依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 自由軟體鑄造場 林誠夏

林先生，您好！
非常感謝您的回答，如此看來這樣的作法依然是頗具爭議性，
在參考了葛小姐的兩篇著作與您的回答後，這個問題目前看樣子還是屬於灰色地帶，
在沒有明確定義以前，我應該會將兩種方式並行採用，
未來若有更清楚的定義或解釋時再行更改。
再次感謝您撥空回答，祝鈞安。

PS.葛小姐著作網址
https://www.openfoundry.org/component/option,com_content/Itemid,353/id,1711/task,view/
https://www.openfoundry.org/component/option,com_content/Itemid,353/id,1788/task,view/