Hi secret715,
原來你使用的版本是GPL-3.0，不過、GPL-3.0就轉授權(sublicense)這點在推論上與GPL-2.0並沒有太大的差異，而在修改標示方面，GPL-3.0一樣明訂：修改他人的GPL-3.0授權元件，必須清楚交待誰修改了它，以及其相關的修改日期。(The work must carry prominent notices stating that you modified it, and giving a relevant date.)所以此處也與GPL-2.0並無兩致。
以下是你追加討論的部份：
1、若新版程式與舊版程式的原始碼完全相同，甚至連版本號也相同，是不是還能夠改變其適用的授權條款？
理論上並沒有說不行，只是、一般來說較建議在這種狀況下，就給這個程式一個新的版本號，會是一個比較清楚讓人好理解的作法！
我們舉例來說，專案名稱為「TIVOK」，第一個版本為「TIVOK 1.0」版，採「MIT License」釋出，之後、雖然程式碼沒有改，也可以稱一個新的版本為「TIVOK 2.0」版，改採「GPL-2.0」或是其他授權方式釋出。此種作法的好處在於，不致讓使用者在查授權資訊的時候產生誤會，目前坊間有一些程式授權狀態的驗證軟體與服務，例如BLACKDUCK或是FOSSOLOGY，這些程式的授權資訊資料庫會註解「TIVOK 1.0」為「MIT License」，而「TIVOK 2.0」版為「GPL-2.0」授權，那麼當查找者可以確認所使用的版本是1.0版時，他們就可以安心使用MIT授權的方式來使用它，反之、如果確認所使用的版本是2.0版時，就可以安心使用GPL-2.0的方式來使用；但是、若是您同一個「TIVOK 1.0」版，之前採MIT License，之後採GPL-2.0，但釋出的時間又有前後的差異，這種狀況會是比較容易造成誤會的，雖然理論上這就是「雙重授權(Dual-license)」，也就是說這些程式碼同時採用MIT與GPL-2.0的方式釋出，只是標註的時間不同，但就是因為標註的時間不同，也許會讓使用者在查找上產生誤會和不確定感，所以、我們在撰文時才會建議，即使是程式碼完全沒有修改，亦不妨給該軟體專案一個新的版本號，再去適用新的授權方式，這樣會是一個避免產生誤解的方式。
例如，「TIVOK 1.0」版，可以使用「MIT License」釋出，其相同程式碼的專案亦是要採用商業服務的授權方式，不妨稱這個商業服務的專案為「TIVOK 1.5」版，採用商業授權的協議來運作，然後其後的「TIVOK 2.0」版，也可以改採GPL-2.0、GPL-3.0這種Copyleft的授權方式，來與「TIVOK 2.5」版的商業授權版本來配合，也就是說，透過這樣的方式，可以讓使用者捉到版本與版本間的傳承關係與授權機制的轉變，「x.0版本」邏輯上皆為自由開源授權，而「x.5」版本皆為商業服務授權，慢慢建立這樣的授權配置之後，軟體專案的授權布局便可愈見清晰，而不易產生誤解。
2、採用GPL釋出程式專案時，若並未在每一個檔案標頭(header file)都註解其採用GPL授權，而是統一在根目錄處置放一個說明檔，此種作法是否已充份表述？
可以的，GPL授權條款並沒有約束每一個創作人，一定要每個檔案都去標註該程式碼的授權狀態，只是、這雖然不是義務，但是一個「作了會比較好的方法」，因為之後別人改作你的程式時，他可能不會整包程式碼都拿去，而可能只是取用其中幾個檔案或是函式檔，如果你本來有將簡要的授權資訊寫在這些重要檔案的檔頭資訊裡，那就會讓整個改作狀態變得「有跡可尋」，而如果該改作者「刻意將這些檔頭資訊拿掉」，日後若發生侵權糾紛的話，他所為的刻意刪除資訊的行為，也有機會被承審法官認為是「明知並故意」侵權的主觀象徵。
這裡稍微簡述一下GPL授權條款在GPL授權標示上一定要作的幾個動作：
(1) 散布GPL授權程式時，一定要附隨散布一份GPL授權條款的全文。(Give all recipients a copy of this License along with the Program.)
所以，大部份的專案會在釋出包的根目錄下，放入一個名為COPYING的純文字檔，該文字檔的內容就是GPL授權條款的全文內容。
(2) 如果個別檔案被修改過，必須要標註修改人為何，以及修改日期為何。(The work must carry prominent notices stating that you modified it, and giving a relevant date.)
因應於此，許多專案會在釋出包的根目錄下，放置一個名為README、REVISION、或直接稱為MODIFICATION的純文字檔，說明哪些檔案有被更動過，以及更動日期是什麼時候。
(3) 如果該程式安裝時有人機互動介面，並且會透過這個介面來顯示個別元件的授權聲明，那麼採用到的GPL元件，必須適當的透過這個介面，讓其GPL授權條款的內容呈現給程式的安裝者與使用者。(If the work has interactive user interfaces, each must display Appropriate Legal Notices.)
在GPL授權方式方面的標示義務，大致上便是如此！
此一問題進一步的參考資訊，可以參照葛冬梅小姐所撰右列專文，如何提供 GPL 元件的程式源碼：
www.openfoundry.org/tw/legal-column-list/8782-how-to-distribute-gpl-source-code
3、他人改作你本以GPL-3.0釋出的程式，後續散布時並沒有附上應有的「標示」，如「本程式原始版本由XXX製作，採GPL-3.0於
www.yyy.zzz釋出。」能夠在事後請他補充標示嗎？
沒有問題，如前所述、依照GPL-3.0的授權義務性規定這也是應該的。你可以聯繫專案的改作人補行這個標示的動作。
4、若是要求上述「標示」必須顯示在程式操作畫面的最上方，且點擊此一標示能連結至原版程式的官方網站，這樣的要求是否符合GPL-3.0授權條款的運作規則？
這樣的要求爭議是比較大的，因為GPL-3.0律定：採用GPL-3.0釋出程式時，關於這些軟體權利的行使，不得向後手課予或要求GPL-3.0條款本身所無之限制。(You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License.)進一步說，GPL-3.0已經有預設授權標示方面的規定了，進一步要細節去要求程式的改作者，進行條款本身沒有描述到的標示義務，很有可能、就會被認為是GPL-3.0此處所說的「條款本身所無之限制」，而被認為是無效的要求。而且歷史上類似的故事曾經有發生過，就是四款BSD授權條款與GPL-2.0是否相容的爭議，因為四款的BSD授權條款要求在授權聲明的標示上有一些細部的規定，而自由軟體基金會認為這些細部要求在GPL-2.0條款裡是沒有的，所以認為四款BSD條款與GPL-2.0不相容。
如果真的要立一些特殊的標示的話，我的建議是應用GPL-3.0第7條第3項b)款的額外添附條款(Additional Terms)！基本上、整份GPL-3.0的條款都是不能被使用者變動的，但是第7條這6款額外添附條款，是GPL-3.0不得變動中的折衷機制，也就是說、使用GPL-3.0釋出自己程式的使用者，可以自主加上這6款額外條款，而其中的b)款，指的是：「原專案的著作人，可以指定程式散布時某些聲明內容是不能被後手刪去的。」(Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it.)透過這款額外添附條款，你可以將你原始專案的網址、運用狀態，甚至你個人的簡介都寫到程式的說明資訊裡，並且要求後手散布改作作品時，也要保留這些聲明。雖然此款似乎也不能指定後手一定要將網址或是資訊內嵌到改作物的操作介面上，但你可以要求如果其改作物有著作權與資訊的說明頁面，一定要將你要求的顯明資訊擺進去。這樣也算是某一程度達到你期待的目標。
5、有哪些自由開源授權條款是可以附加其他限制條款的？
基本上，所有的自由開源授權條款的內容，你都可以拿來改作，只是一旦你更改了授權條款的內容，後續應用上，你便不能再稱其為原來的授權條款。例如、你可以拿BSD授權條款來改為AAA授權條款，將自己的程式以AAA條款釋出，也可以拿GPL-3.0授權條款來改為BBB條款，將自己的程式以BBB條款釋出，但這些改作過的條款，泰半與原來的授權條款便不再相容了。會這樣發展的原因是，自由開源授權強調的是一種多人共工的發展模式，所以條款預設的架構就是大家都用同一份條款、同一份規則，這樣專案經過許多人的修改與改作後，仍然有可能與原本的程式碼，或是之後延展出來的程式碼，在同一個規則下相容。
而如果說授權條款本身即設有「附加限制條款」的，目前看來大概就是GPL-3.0、LGPL-3.0，以及AGPL-3.0，於前述的第7條項下設有「額外添附條款(Additional Terms)」，讓使用者能在這6款的限度下去調用，然而、也就僅限於此預設6款的內容。
如果你對於這些額外添附條款有進一步了解的興趣的話，可以進一步參照拙譯，GPL-3.0-非官方正體中文翻譯：
lucien.cc/lucien/doku/doku.php?id=notes_and_translations:foss_license_translations:gnu_general_public_license_version_3
不過在此特別聲明，自由軟體基金會並不允許任何人將GPL授權條款進行翻譯並進行運用，其所發布之英文版本方為具解釋性的唯一可參照版本，所以這裡的非官方譯文，僅是讓大家可以據以討論、參考之用，並不具任何法律效力。
與額外添附條款相關的文字我亦節錄在下，供你可以直接閱讀。
----
散布者在取得原權利人同意或是滿足其預設的要求條件後，能夠添附以下六款「額外添附條款」至GPL3授權條款內，再依此複合狀態的授權規定將程式再行散布出去，此六款「額外添附條款」的實際內容如下：
a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
1、宣告與GPL3本文第十五條及第十六條有別的免責條款或所謂的責任限定條款；
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
2、要求後手在程式的後續傳遞過程中保留原權利人合理的相關法律聲明，比如顯名式的著作人格權保留或其他合理聲明等；
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
3、禁止後手刻意混淆修改作品與原作品的同一性，或是由原程式的著作人要求修改者，須以不同的版本號或清楚的聲明宣示此衍生作品為一修改物，以公示釐清修改版本並非出於原程式著作人之手，而不至於將修改版本日後的技術瑕疵或法律爭議無辜地歸咎於程式的原作者；
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
4、禁止後手在未經允許的狀況下，以原程式著作人的名聲為後續版本進行宣傳或為修改程式的品質背書；
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
5、原權利人明示其在商標法的允認範圍內，禁止收受程式的後手使用者在未經允許的前提之下運用這些商標及相關的各式商品服務標記。
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
6、原權利人可添附「損害發生補償條款(契約責任禁止添加條款)」。有時後續散布GPL程式者，會與收受程式者議定不同於GPL原始散布狀態的契約責任，這些契約責任的內容甚至可能波及程式的原始著作權利人，或是其他參與程式修改的接續作者也得擔負這些額外的責任。如果擔心這樣的事情發生，原權利人便可據本項規定添加「損害發生補償條款(後續契約責任添加禁止條款)」再將程式釋出，來加以明示防堵，意即、程式的著作權利人得利用此項聲明，明文表示、若程式後續散布者與他人簽訂契約散布此一程式，後續卻讓其負擔權益上的損害，則此程式的後續散布者便須依照「損害發生補償條款」的規定，補償其因此而產生的權益損失。
----
最後，其實我個人非常歡迎大家能在這個論壇，一同發掘自由開源授權的議題並進行討論，因為這本來就是我目前生涯職志有興趣做的事，也希望能在自己研究所學之餘，盡量將中道、可參據的相關資訊與知識分享出來讓國人知道，所以、並不會覺得是耗費到時間。
然而、有時候工作事務上較繁忙之時，難免回覆的速度會有所拖累，就這點、再請見諒。
祝你 新春愉快、事事如意
20130221 15:10 LUCIEN C.H. LIN
Favoured: 1
