林教授您好，
GPL授權的元件在授權拘束性方面是較為擴張，依照GPL授權條款的文義解釋以及一般通說，其他程式涉及對GPL程式靜態連結方式的互動，或是功能整體評估上「質與量」高度相依狀態下的「衍生關係(derivative work)」，都會開啟這樣的授權拘束性。這樣的授權解釋主要是在GPL-2.0右列這段文字：These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
簡要來說，重點在於個別元件和GPL-2.0元件之間有沒有衍生關係，如果個別元件確實是衍生自GPL的元件(work based on GPL-ed component)，而且又與這個GPL-2.0授權的元件併行散布，那麼此時這個衍生元件就必須以GPL-2.0的方式來授權散布。所以如果要讓該元件與GPL-2.0元件之間沒有授權拘束的關係，一般來說可以透過兩個方式處理：一、主張該元件確實非衍生自GPL授權元件libnids，二、主張該元件可以與其他BSD、MIT，或是MPL授權的其他自由開源元件互動，也不必然要依賴GPL授權的元件。
一、主張該元件確實非衍生自GPL授權元件libnids
要達到這個主張，首先您自行撰寫的元件裡必須不含括GPL授權元件的程式碼進來，再者、也必須佐以其他理由來主張，例如Linux Kernel裡部份的driver是從Unix時代就有的driver再轉植裡來的，這部份的driver，Linus Torvalds就認為不能算是Linux Kernel的衍生著作，因為這些driver的寫作時期大抵早於Linux Kernel，所以實在從難說因為它內嵌於Linux Kernel下，就必然是Linux Kernel的衍生著作。
二、主張該元件可以與其他BSD、MIT，或是MPL授權的其他自由開源元件互動
實務上有些專案的運作，會同時提供GPL授權的函式庫與MIT授權的函式庫，功能上使用GPL授權的函式庫能得到更佳或更豐富的表現，然而使用者亦可以自主選擇MIT或其他授權方式的函式庫，此時功能表現上雖略遜，然專案整體仍可運作而不會失去主要功能，那麼多數的社群開發者在這種狀況下都會同意「該專案並非整體皆為GPL授權函式庫的衍生著作」，從而便不必然為GPL授權拘束特性所執。
好的，那麼照這樣的概念，簡要回覆您的疑問：
一、向作者徵詢同意另行以非GPL的方式授權給我們，此方式可行嗎？
法律狀態下是可行的，但推論之下可行性不高。依據libnids的相關說明，其部份模組採用修改自Linux Kernel的檔案(CREDITS: Libnids emulates algorithms present in Linux 2.0.36 kernel. The files ip_fragment.c and ip_options.c are the modified respective files from Linux 2.0.36 kernel source. The asm code used for checksums computing is taken from Linux 2.2.10 kernel source.)，那麼這些模組因為有Linux Kernel程式碼直接抄寫的關係，所以必然是GPL-2.0授權的檔案，然而，若是該專案的作者同意，理論上也可以在剔除掉這些直接衍生自Linux Kernel的檔案，然後將其他程式碼以其他的授權方式提供給您。不過，我個人認為因為libnids近期可能還不會進行這樣雙重授權的處置，因為它官方網站上表述的是該專案是多人著作，雖然主要是由Rafal Wojtczuk所設計的，但亦容有其他多人的貢獻(Libnids is designed by Rafal Wojtczuk. Numerous people have contributed - see the README file in the source directory.)，而且這些個別作者的資訊都註記在檔案根目錄下的CREDITS檔裡，理論上，libnids要轉授權的話，需要這些作者共同或是多數的同意方可為之，也並不是Rafal Wojtczuk先生說了就算，所以我想目前這個階段，得到另外授權的可能性並不高。
二、於自己元件與GPL授權元件之間寫一個中隔的程式，讓自行撰寫的元件與GPL授權元件僅透過中隔程式來進行互動，這樣的方式能夠隔開GPL授權元件的拘束性嗎？
實務上不少廠商確實是這樣做，不過因此在歐洲與美國收到作者侵權警告信的狀況也不少。因為單單只是透過小程式來中隔，大抵無法通過著作權法上衍生關係在「質與量」綜合評估方面的判準。其實是這樣，著作權法與GPL授權條款在判斷授權拘束時，重點都在於「是否為衍生關係」，而並非元件與元件之間是如何互動的，只要是非衍生關係，則就算元件間高度緊密互動，也不一定會讓A元件、B元件必然會被GPL授權的C元件所執，而只要是衍生關係，則不論元件間是不是另外散布，則使用上也會引開GPL授權上的爭議。實例上，目前用中隔方式做到二個較不會引發法律爭議的，一為Google Android的中隔層，二是Nvidia之前釋出能跑在Linux Kernel上的驅動程式，前者，是因為Android上的中隔層程式碼的數量與質量皆非常的高，並且本身也以Apache-2.0來釋出程式源碼，再加上Linus Torvalds寬鬆的解釋Linux Kernel其上具有不受Kernel限制的User Space，所以這樣的作法得到多數Kernel開發者的「接受」；而後者，Nvidia強調其釋出的驅動程式，在Windows和Linux下都是用基本的同一套程式碼，只是二個版本依作業系統的不同而調整了不同的對應方式，所以Nvidia主張該驅動程式既可以跑在Windows作業系統之下，又同時可以跑在Linux Kernel之下，那麼這些驅動程式因可以在不同平台下操作，則應非Linux Kernel的衍生著作，而可以不必然使用GPL授權條款來向外散布，此一主張Linus Torvalds公開表示不甚滿意，但除此之外，也就沒有採取後續相關的法律途徑。
所以說，試舉例以「質量相當」的分析觀點來看中隔程式，如果是A元件有3000行程式碼，透過300行程式碼的中隔層，來阻卻20000行程式碼的GPL元件，那一般來說這會被自由開源軟體社群視為實質GPL授權義務的規避，如果沒有其他能主張「獨立性」的理由，則以當前的狀況而言，並沒有辦法完全阻斷後續發生法律糾紛或是網路非議的可能性。
三、參考BSD或其他permissive的自由開源授權元件，來重寫該Library的程式碼，此種作法是否便可根除GPL授權拘束性的相關義務性要求？
當然，參考BSD或是其他permissive的自由開源授權函式庫，來改寫成自己所需要的函式庫，則日後散布大抵僅要註解原專案作者的顯名聲明，則就可以自由地利用這些程式碼，而BSD、MIT、Apache-2.0明文或是解釋下都是允許再授權(sublicense)的，所以也可以將改寫過後的程式碼封閉起來，改用自己的授權方式來散布該元件的目的碼。
不過，其實著作權法上「改作」與「重新創作」是兩個不同的概念，「改作」代表您改寫的專案裡，還包有該專案之前作者的程式碼，這種狀態下，您必須先取得該作者的明示授權之後才可以進行改作，而其實各種的自由開源軟體授權條款，都有明示授權「改作權」予您，只是您得到這些改作權的前提，就是得遵守這些條款個別的授權義務性規則，例如MIT、BSD、Apache-2.0主要是保留原著作的顯名聲明以及免責聲明；GPL類別的條款，則要求除了顯名聲明、免責聲明之外，若是衍生關係還會拘束到您自行撰寫部份的授權狀態；但「重新創作」的話，您其實可以不必遵照這些條款各項授權規則，這是因為著作權僅保護著作之表達，不及於著作背後的思想與原理(我國著作權法第10-1條：依本法取得之著作權，其保護僅及於該著作之表達，而不及於其所表達之思想、程序、製程、系統、操作方法、概念、原理、發現。)，所以，即使是GPL授權的元件，您亦可以在閱讀它元件程式源碼之後，嗣後自行依著一樣或是相近的邏輯自行編寫一個獨立專案出來，重點是不能用直接抄寫，或自動化轉譯、編譯的方式來利用原元件的程式碼，簡單來說，只要是學習之後重行自己以近似Clean Room的方式寫出相同功能的軟體專案，則這是一個重新創作的非衍生關係，非衍生關係的話，您自行撰寫的獨立元件，便可依您的意思自行選擇適用的條款來應用。
所以說，有下列幾種解套方式，可供您參酌：
- 選擇相近功能的BSD、MIT、Apache-2.0授權的元件來改寫成適用的函式庫，這種作法可直接抄寫原專案的程式碼。
- 就libnids專案進行重新創作，建議是在了解其運作邏輯之後，以不參照libnids程式碼的方式自行重新撰寫，該新創專案的授權方式能夠由您自行決定。
- 您目前開發的程式是透過call function的方式來與libnids互動，如果您能另找一個MIT、BSD、Apache-2.0授權的近似專案，並讓使用者在使用您專案時，能自行選擇要用GPL-2.0授權的libnids，或是其他授權方式的函式庫，則可以例外主張自行研發程式應用上的獨立性，此時主要必須披露的內容為該程式與libnids之間的互動資訊，以及和其他授權方式函式庫之間的互動資訊，此部份的披露資訊，如能夠讓libnids未來升級版本時，使用者也可以將新版本的libnids置換到專案或是相關產品中，而專案／產品仍然可以運作無誤的話，則大抵這種作法涉及GPL侵權的爭議和風險就是很小很小了，因為該GPL-2.0授權程式在您的專案與產品中並不受限，從而不會引發軟體社群所謂「將開源的元件置於不開放的環境下運用」的相關議論，而更能夠進一步主張僅為單純利用GPL授權函式庫的方式(use the work)，而不是衍生關係的利用(work based on the program)。
相關資訊約略如上，如後續再有相關的問題，亦歡迎您接續來與我討論。
敬祝 順心健康、事事如意
:)
20121130 1205 自由軟體鑄造場 林誠夏
我們目前開發的程式因為有重組網路封包的需求，所以在程式中以callback function等形式呼叫libnids這套open source library內的function來做封包重組，這套library 的作者因為有用到Linux kernel的source code，因此也必須使用GPL (v2)。 但因我們的程式日後可能會技轉給廠商，所以GPL的問題變成需要顧慮的地方。
我們目前只有link與call這個library中的function，完全沒有修改該library的程式碼。就我對GPL的了解，我們的程式應該也必須是GPL (?)，除非該library用的是LGPL。但由於如果要重寫整套library會耗費掉太多的人力，這也是我們最初使用這套library的原因，因此希望能尋求解套的方式。
目前可能有幾種選擇，敬請提供建議：
- 向作者徵詢同意，讓我們的程式不用掛GPL，但這似乎違反GPL的規範，不知是否有此可能性? 或是有任何其他豁免的方式?
- 另外寫一支小程式去使用這個library，讓這支小程式與我們目前的程式獨立出來。然後讓我們的程式的輸入來自於這支小程式的輸出。這樣是否可以讓我們主要的程式不用掛GPL? 這個選擇的另一個缺點是日後廠商如果要改到那支小程式(必須得掛GPL)可能一樣會遇到GPL的問題。
- 我們重寫那個library的code，一種可能就是參考其他(如BSD license)的code，來加速我們重寫的速度。這樣應該可以讓我們的程式免除必須用GPL的顧慮。如果整個重寫會花費較多的人力，這是我們較不傾向的做法。但若沒有更好的選擇，也只能如此。
如果林先生有其他更好的解套方式，也請提供建議。非常感謝您的指導。
祝 順心
柏青 敬上