依據 GPL 規定，散布 GPL 程式的人，必須要提供程式源碼給拿到 GPL 程式的人。按照字面意義，所謂的源碼就是程式修改源頭的原始碼 (Source Code)，也就是其他開發者可以很方便接續修改這個程式的形式。不過 GPL 在定義源碼範圍的時候，特別提到、若是該專案為一個可執行程式的話，完整的源碼還包括了介面定義檔、控制編譯過程的腳本與安裝資訊，GPL-3.0 更進一步規定，這裡所謂的源碼包含可以讓程式編譯、安裝起來的所有原始資訊，按照這樣的規定，所有該程式相關的必要編譯工具組 (toolchain)，也都包括在這個定義範圍之內，進入散布時必須提供的清單之列（註一）。可是有關程式元件相關的額外資訊，其實並不皆為程式運作時必要的附加物，甚至有些是使用者自己撰寫，完全沒有引用或包含到 GPL 元件的程式碼，在這樣的情況下，許多人常常便會產生疑問：此時使用者自行撰寫的額外資訊，也都必須要依照 GPL 的義務性要求提供出來嗎？

討論這個問題我們可以切成兩個不同立場來看！首先、從自由開源軟體推動社群的理念角度來看，其撰寫 GPL 程式的目的，是為了讓有能力的程式開發者，可以自行研究與修改該程式，讓程式因此變得更好用，並且也不會在接續修改、後續散布的過程中，讓後手將相關的程式源碼封閉起來。為了達到這個目的，除了讓使用者可以修改程式外，還必須要讓開發者可以編譯程式，並且安裝起來，這樣開發者才可以知道修改後的程式執行起來效果如何。在此種思維下，若一個可執行程式採用 GPL 授權的話，除了單純的程式源碼，使用者在散布程式的時候當然必須一併提供該程式的安裝與編譯資訊，以及必要的相關工具，以讓拿到程式的後手開發者，可以盡興地修改、研究這個 GPL 授權程式與其衍生程式（註二）。

然而、從一般商用自由開源軟體廠商的角度來看，其取用 GPL 元件加入自己的商業產品時，固然因為授權條款明確的規定，其對直接自 GPL 程式衍生出來的程式碼，必須要擔負一併提供程式源碼的義務，然而其在遵循此項義務時也會產生疑惑，那就是：針對該 GPL 元件與其他元件互動的優化與調校資訊，有時並不直接涉及程式碼的引用與改作，這部份的額外資訊，也會被列入必須提供的清單之列，而喪失掉公司商品競爭的優勢嗎？而 GPL 授權條款這樣的進階要求，又具不具有法律上的強制拘束力呢？

其實、中道的就這個議題來做分析，GPL 授權條款就此議題的義務性要求，確實較諸著作權法的預設幅度還要廣，然而、以契約條款補充法律預設條文的不足，本就是私法經濟下契約自由主義所容許的大原則，也就是說、如果程式的使用者不同意 GPL 授權條款此項要求，其仍然具有拒絕使用 GPL 授權元件的自主權，而倘若程式的使用者，已將 GPL 授權的程式碼編寫進自己維護的專案裡，那麼基於著作權法的預設規定－「權利人保留所有權利 (all rights reserved)」，取用他人擁有著作權利的程式碼必然要預先得到其合法授權，所以使用者取用 GPL 授權程式碼的行為，已經是以「意思實踐」的形式，來公開承諾接受 GPL 授權條款的諸般義務性要求，此時、以 GPL 授權條款的內容來論，其就狹義程式碼之外的編譯與安裝資訊提供義務，既已明文列示要求，那麼這樣的義務性條款如果不是顯失公平的話，那原則上便應會被全球各地的司法機構所共同肯認，而認為具有契約義務的執行效力。

這樣的話，一般 GPL 程式的使用與再散布者，對於所提供的資訊應該要做到什麼樣的的詳細程度呢？最佳狀態，當然是附上一個步驟一個步驟的編譯與安裝資訊，甚至連相關的工具組也一併附上。而最低程度，筆者以為必須要做到，一般具有相關領域基礎知識的程式開發者，皆可以循著該程式源碼所提供的資訊，將所提供的程式源碼編譯、安裝並執行起來，而若是這樣的標準也沒有達到，那就表示所提供的資訊太過簡略。比喻來說，這些編譯與安裝資訊就好比是學生上課的筆記，有的學生筆記做得詳細，缺課同學借來看，如同親臨上課一般，詳盡的編譯與安裝資訊就像是這種筆記。有的上課筆記比較簡單，只有大綱與重點說明，缺課同學借來看雖然無法馬上就理解吸收，但是經過一番思考，與搜尋、參考相關資料之後，仍然可以理解老師上課的內容，若所附上的編譯與安裝資訊可以達到這樣的效果，筆者以為這就達到了最低標準。而有的上課筆記非常簡略，只有重點、大綱，甚至只有一些關鍵字，這樣的內容只有做筆記的同學自己可以看得懂，缺課同學拿到之後，除非詢問原來做筆記的同學，否則根本無法理解筆記的內容，若所提供的編譯與安裝資訊也是這樣簡略，對於其他開發者來說，有如無字天書，並無法達到協助他人安裝執行程式的目的，這是筆者認為最易引發授權糾紛與爭議的狀況。

另外關於工具組的利用方式，筆者想要特別說明。有人以為所提供的工具組，僅是單純作為工具使用，所以有沒有提供程式源碼都不重要，其實若所提供的工具組也是採用 GPL 的方式進行授權的話，那麼自然也必須要依照 GPL 授權條款的相關規定，將該工具程式的源碼也一併提供給後手開發者，這並不會因為該工具組所帶有的工具特性而受到影響，舉例來說、以 GPL 授權方式釋出的 GNU Compiler Collection，若隨專案產品一併散布，就屬於此種狀況。而若所提供的工具組不是採用自由開源軟體的授權方式釋出，並且其所提供的功能偏向輔助開發，而非為該 GPL 授權元件運作上所必然需要的話，那便有機會除外於 GPL 授權條款的拘束範圍，而可能不需要提供這部份的額外資訊。然而、此處特別彰明一個現實上可資參照的判斷標準，一般來說、原 GPL 授權專案的開發者所提供的編譯與安裝資訊愈詳細，則其要求後手修改者必須接續提供的衍生資訊標準便愈高，而若原 GPL 授權專案的開發者本身所提供的原始資訊本就較為貧乏，自然也不會向後手修改者要求太多衍生程式的細節資訊。

最後附帶說明的是，許多自由開源軟體專案的參與者，其強調的是開放、分享的精神，希望透過互相分享、討論的方式，來達到研究、修改，進而改善程式的目的，基於這樣的理念，許多開發者願意將自己撰寫的程式源碼以免授權金的方式提供給他人利用，所要求的回報不外乎就是尊重其授權理念，而尊重的具體表現就是遵守授權條款的相關遊戲規則。雖然 GPL 在提供編譯與安裝資訊這方面的規定，不見得會受到不同立場的使用者所共同欣賞，但是若從自由開源軟體整體的發展環境來說，筆者認為在提供程式源碼的同時，也可以盡量以詳細的方式來提供這些資訊，甚至是相關的開發工具組予後續的專案開發者，如此才有機會吸納有志的社群開發者，與商品供應鏈 (supply chain) 上的其他上下游廠商一併加入協力共工，將自由開源專案的開發帶入良性、正面的循環中，並讓此專案的開發整體朝向正面的方向來推進。

---

註一：GPL-2.0 第 3 條第 2 項：「The source code for a work means the preferred form of the work for making modifications to it. For an executable work, 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. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.」。GPL-3.0 第 1 條第 4 項也有相對應的規定：「The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.」

註二：為了便利開發者研究、修改與改善程式，除了附上詳細清楚的編譯與安裝資訊之外，詳細的技術說明文件也是不可或缺的一環。透過這些文件與資訊的提供，自由開源軟體開放、共享的精神才能真正體現，將軟體的開發與改善帶進一個良性的循環。不過技術說明文件的提供與授權方式並不在本文討論之列，因此文中並未提及，在此一併說明。對於這一議題有興趣者，可以參考：林珈宏，自由開源軟體說明文件的授權選擇，自由軟體鑄造場電子報第 127 期：https://www.openfoundry.org/index.php?option=com_content&Itemid=56&id=2076&task=view/。