這是本文件的舊版！
GPL 授權的圖示
葛冬梅／文 2009-02-20
GPL 這個授權條款一般來說是適用於「軟體授權」的狀況，但是近年來也看到不少採用 GPL 來授權圖示的例子（註一）。但令人疑惑的是：因為 GPL 授權條款的內容主要是規範軟體授權的運用方式，尤其是要求釋出程式目的碼 (binary code) 的散布者，也必須肩負後續提供程式源碼 (Source Code) 的義務，那麼以 GPL 散布圖示的時候，是不是只要將圖示的圖檔提供出來，便就符合了 GPL 散布者提供源碼的義務？而若是將 GPL 授權的圖示匯入自己開發的專案來使用，會不會因為圖示的部份是 GPL 授權，也導致專案的授權方式也受到影響呢？
上述的問題光看 GPL 條款的文義解釋，並無法直接得到明確的答案，因此筆者從探究契約法的法理原則與 GPL 授權的四大自由開始，來尋找這個問題的答案。
首先從契約法的相關論理談起，一般契約法的原理原則是讓契約內容盡量有效，例如民法第 111 條規定：「法律行為之一部分無效者，全部皆為無效。但除去該部分亦可成立者，則其他部分，仍為有效。」並且參酌 GPL-2.0 授權條款第 7 條第 2 項的內容：「If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.」可知即使以 GPL 授權條款來釋出圖示並非其預設的對象，然而只要個別條款在應用上仍然可行，那麼這些個別條款便應仍然有效，而可以被合法適用。這就像是以定式的不動產租賃契約來出租停車格一樣，單一停車格的租用、並不會有水電與管理費分擔的權利義務關係，然而定式契約裡面水電費與管理費相關條款的不能適用，並不會造成整份契約都完全無效，締約雙方還是可以就這份契約裡可以適用的範圍來分配彼此的權利義務關係。
所以從上述觀點可以知道，以 GPL 條款釋出圖示的法律行為仍然是有效的，但細節就是、哪一部份的條款內容可以被適用，在適用上又應該如何做調整與解讀呢？
筆者就這個問題有兩層的邏輯推論：第一層推論的想法是依照 GPL 授權條款可適用的規定，以及參酌四大自由的精神，只要該散布者，提供了圖示的編輯圖檔，就已經達到 GPL 提供程式源碼的義務；而第二層推論的想法則是，將 GPL 授權的圖示匯入其他軟體專案中使用，應該可以僅提供該圖示的編輯圖檔即可，軟體專案的其他部份，還是可以使用散布者選擇的其他授權方式，而不會產生授權拘束性方面的問題。
這裡的第一層的推論是直接將 GPL 的義務性要求，以及四大自由的邏輯套用到圖示的狀況裡！GPL 的撰寫目的是為了要實踐四大自由：「使用者有執行程式的自由、研究讓程式適合己身需求的自由、再散布程式的自由，以及改良程式並將改良內容發布出來的自由（註二）。」為了實現這四大自由，GPL 授權專案的程式源碼必須隨同軟體目的碼一同散布，或是取得目的碼之人、也可以嗣後再向散布者索取程式源碼，而程式源碼的範圍、也必須是對應上最適合用來修改該專案軟體的完整版本。所以、一個圖示若是採用 GPL 的授權方式向外散布，圖示本文亦必須要可以被使用、研究、修改、再散布，並且允許他人擷取其中的構思來改良其他的圖示，如此才符合 GPL 的義務性規定，以及四大自由的精神。
所以在圖示的情況下，提供方便編輯的圖示編輯檔，便已經非常貼近 GPL 所代表－便利後手修改的精神，倘若該圖示只有單純的顯示格式，那此顯示格式便為其最高階的編輯格式，而為此種狀況下的圖示源檔，但如果此圖示在顯示格式之外，還有其他更適合被用來修改的編輯檔格式，那就應該要一併散布此編輯檔格式為其圖示源檔。此外、進一步思考，軟體與圖示的自然呈現方式不同，所以兩者修改的難易度也有不同。就軟體的狀況，透過修改目的碼來達到修改軟體的目的具有相當高的難度，因為目的碼並沒有辦法明顯呈現出軟體的撰寫邏輯與架構；但在數位圖示的情況，即使沒有編輯檔、想要修改圖示的人仍然可以直接修改它的顯示圖檔，雖然不像直接修改編輯圖檔一般的容易，但是卻也不會像修改軟體目的碼那樣的困難。因此、在散布 GPL 授權圖示的時候，筆者以為、散布者能夠直接提供編輯圖檔是最好的方式，但若此圖示本來便僅具一般常見的顯示格式，那麼便以這個顯示格式作為該散布行為裡的圖示源檔，這樣也便足夠了。不過當然，所提供任何格式的編輯圖檔都必須是可以被後手修改的，若是在圖示檔案裡添加了數位權利管理 (digital rights management, DRM) 的相關技術，來禁止他人後續修改這個圖示的話，那當然也就不符合 GPL 的授權規定與條款精神了。
而在第二層關於授權拘束性方面的推論上，筆者認為、將 GPL 圖示匯入到軟體專案中來應用，該軟體專案的其他部份，並不必然得要採用 GPL 授權條款來向後散布！這是因為在一般情況下，圖示的可取代性與替換性很高，軟體專案本身並不會因為缺少哪一組圖示而產生功能上的缺陷，多數的狀況、缺少的圖示一樣可以採用另外一組圖示來進行替換，所以筆者基於 GPL-2.0 第 2 條第 2 項對於程式元件「獨立性」的判解（註三），
以為使用 GPL 圖示並不會讓軟體也必須採用 GPL 授權。但若是有人修改 GPL 圖示，依照 GPL 的 copyleft 精神，被修改過的圖示仍然必須採用 GPL 來授權。
除了 GPL 授權的圖示，搜尋網路上可以讓人自由使用的圖示，還會發現不少採用 LGPL 與 CC（註四）授權的圖示。CC 的授權內容本身就適用各類的圖文創作，所以不會有 GPL 適用到圖示上所併隨產生的條款解釋問題。LGPL 與 GPL 背後所代表的精神一致，都是發揚四大自由，因此筆者以為，散布 LGPL 圖示時，僅提供他人可以修改的壓縮圖檔就可以滿足 GPL 的要求。那麼利用 LGPL 圖示，是否會讓軟體也變成 LGPL 授權呢？筆者以為不會，因為 GPL 與 LGPL 並不完全相同，單純連結利用 LGPL 函式庫的軟體可以自由選擇授權條款，並不必須採用 LGPL 來授權，這樣的邏輯套用在 LGPL 圖示上，表示單純利用 LGPL 圖示的軟體當然可以不需要採用 LGPL 授權，這樣的推論結果與利用 GPL 圖示相同。
還記得最初看到這些採用 GPL/LGPL 授權的圖示，蠻驚訝的，因為這些條款的內容都是以程式碼為客體來規範，套用到非程式碼的著作物之上，真有些格格不入！筆者自行臆測，之所以會有這種現象產生的原因可能有二：一是這些圖示最初就是要被創作出來利用到 GPL/LGPL 軟體上，配合軟體的授權方式，圖示也採用 GPL/LGPL 授權，二是單純希望自己的圖示可以廣被利用，而 GPL/LGPL 是相當有名的授權條款，因此就採用了！雖然透過解釋，GPL/LGPL 應用到圖示似乎沒有太大的問題，但這畢竟不是最適合的授權方式，因此筆者建議可以採用 CC 授權，若是想要圖示既配合軟體的 GPL/LGPL 授權，又想讓他人可以在非軟體的領域隨意利用，筆者建議可以採用雙重授權：讓圖示使用者可以在 GPL/LGPL 與 CC 兩者中自由選擇，若是使用者想要將圖示嵌入到 GPL/LGPL 軟體中，那他可以宣告圖示也是 GPL/LGPL 來授權，若他想要將圖示嵌入到一幅畫中，創作出另外一幅新圖畫，那他可以採用適合圖文創作的 CC 授權，以避免採用 GPL/LGPL 所產生的格格不入現象。
註一：筆者這邊隨意 google 出兩個當作例子參考：圖示 kNeu：http://linux.softpedia.com/get/Desktop-Environment/Icons/kNeu-5497.shtml，圖示 Yasis：http://www.silvestre.com.ar/?p=6。
註二：四大自由與自由軟體：http://www.openfoundry.org/index.php?option=com_content&Itemid=14&id=1448&task=view/。
註三：GPL-2.0 第 2 條第 2 項：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.
註四：CC，Creative Commons，創用 CC。中文介紹資訊可以參見「創作分享，快樂使用－簡介創用 CC 授權 」宣傳手冊，下載網址：http://creativecommons.org.tw/gallery/Material/cchandbook_edu_2008.pdf。
