嗨~ 各位好:
GPL要求必須在修改過的檔案中附有明顯的說明，請問這樣的說明有什麼特定的格式嗎？
若是使用者甲有某個元件Ａ裡面有很多檔案都有更改過，但如果甲不想替Ａ中修改過的每個檔案都附上說明，
只在元件Ａ裡附上一個說明寫：此元件Ａ經甲修改過，這樣算是違反GPL嗎?謝謝~

Hi Kurapika,

以GPL-2.0為例，這個問題的討論依據是照下面這條義務性規定：

"You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change."

(你可以修改並散布這隻以GPL-2.0授權的程式，但必須將每一個修改過的檔案都帶上明顯的修改標註，說明你修改了哪些檔案還有它們被修改的日期。)

這條規定說明的是，GPL-2.0程式的使用者有權修改該程式並進行後續散布，但於再散布時、需要將其對程式特定檔案所作的修改資訊標註出來，特別是該檔案的修改日期更是不可或缺的必要資訊。

而依據上面這條規定與實務上我與其他鑄造場同仁觀察到的作法來回應您提出來的問題，

問題一、「這類的說明有什麼特定的格式嗎？」

簡答、目前沒有，但部份完全不標註修改資訊或是標註過於簡略的廠商確實有收到警告信的案例。

以最嚴格的文義解釋來看的話，GPL-2.0這條規定確實是要求，這些程式的修改資訊，是要被內嵌到「每一個被修改的檔案」之上，所以、

1、有些專案確實是在每個檔案的header file都置放過修改資訊

有些GPL專案的開發者，會直接在每個file的前面都安置簡單的授權聲明，例如「2009 © Mr. Small and Miss Big, the software/file is licensed under GPL-2.0, modified by Miss Big in 2010/10/15, more details could be found in the COPYING file.」

然而、現實狀況而言，也並不是人人都會這麼鉅細靡遺的去在每一個檔案中一個個明列這些資訊，

2、有些專案的開發者是在該隻程式的目錄下留置一個說明檔案

這個說明檔案可能是一個純文字檔，也可能是一個修改歷程的樹狀圖，裡面即統一標註該目錄下哪些標案是在什麼時間點被修改掉的，這樣的方式雖然沒有上述內嵌到個別檔案那麼的縝密，但畢竟該附上的資訊都附上了，所以實際上也沒有引發直接法律爭訟的案例。

但若是

3、僅註明程式本身經過修改，但並不標註哪些檔案是實際被修改過的，以及其修改日期。

我這邊的資訊是不論歐洲還是美國，都有發生過相關的警告案例，也就是說、權利人或是下游舖貨商發現內含GPL-2.0程式碼的產品，有這個修改資訊標識不明的狀況，進而發函予這些產品的製造商，要求製造商必須補足該GPL-2.0授權程式的：(1)個別檔案修改資訊(2)確切的修改時間記錄，之後才同意其可以續行販售這些產品。

所以我的建議，如果在開發的過程可以設置嚴縝的開發資訊記錄簿，並採用「1、在每個檔案的header file置放修改資訊」是最低風險的作法；然而、若是過往產品已經資訊不足而力有未逮，則亦應補足「2、在該程式的目錄下留置一個說明檔案」以降低風險；而若真的是完全不欲標識或是僅就整體程式做簡略的聲明，則未來該產品在散布時遭逢的爭議性最大，可能的狀況就是在爭議發生時，還是得回溯整理出相關資訊來亡羊補牢了。

希望上述的資訊對您有所幫助，後續若還有衍生問題歡迎隨時接續討論。

20110728 1047 Lucien C.H. Lin

Kurapika wrote:
嗨~ 各位好:
GPL要求必須在修改過的檔案中附有明顯的說明，請問這樣的說明有什麼特定的格式嗎？
若是使用者甲有某個元件Ａ裡面有很多檔案都有更改過，但如果甲不想替Ａ中修改過的每個檔案都附上說明，
只在元件Ａ裡附上一個說明寫：此元件Ａ經甲修改過，這樣算是違反GPL嗎?謝謝~

Hi, Lucien,
我又想到一個問題,
有些公司其開發所用到的GPL source code來自其上游的廠商提供,
而上游廠商也沒在其所更改過的程式碼附有經其更改及更改日期等說明,
那麼這些公司要怎麼寫GPL修改資訊的說明呢?
謝謝~

如果公司知道上游廠商是用 GPL code，那就應該要請上游廠商提供合乎 GPL 規範的相關資訊給公司。至於公司要怎麼知道上游廠商有用 GPL，那就是要在他們之間的契約明定，如果有用到自由軟體的話，要把用到的程式是哪些及他們的授權情況，列出一個清單。這樣上游如果都沒列，或列不全，導致後續公司非故意地違反 GPL 而被告，則公司可以反過來跟上游廠商提告。

Hi Kurapika,

原則上這個法律關係是層層負責，GPL授權條款規定的是散布GPL程式目的碼者，對其散布者、有同時或是嗣後提供GPL程式源碼的義務。

所以若是程式目的碼的散布方式如右所列：甲（軟體元件承包商）→乙（軟體專案統合商）→丙（品牌商）→丁（產品買受人）

則程式源碼的索取關係，便逆向如右所示：甲（軟體元件承包商）←乙（軟體專案統合商）←丙（品牌商）←丁（產品買受人）

也就是說、這個程式目的碼與源碼散布提供的關係，存在於甲乙之間、存在於乙丙之間、存在於丙丁之間，但原則上並不會跨越兩兩相對的傳輸鏈；而所謂「登錄程式碼更改資訊與更改日期等說明」，其實也是兩兩相對、個別負責的。

所以若是「產品買受人丁」向「丙品牌商」提出想得到程式源碼更改資訊與更改日期的要求，但「丙品牌商」手上卻沒有這些資訊，此時「丁」也沒有辦法直接越過「丙」去向「乙」要求這些資訊，而必須是「丙」先去向「乙」要求並得到資訊之後，再轉手傳遞予「丁」。

當然、如果「丙」已經受到要求須提供程式碼的修改資訊/修改日期，但其手上真的沒有該GPL元件的相關資訊，理論上、其可以透過訴訟的方式來催促「乙」提供程式源碼，然而、在一般商業行為上，「甲」、「乙」、「丙」之間的關係常常是長期的商業合作夥伴，若是透過司法訴訟可能也不是一個維繫合作關係的好方法，那麼建議就是商業性的開源元件散布上，可以透過「軟體清單」的作法來處理，也就是說、當「甲」將軟體散布予「乙」時，明訂一張軟體清單，那麼日後若發生問題，就依清單上的資訊來做源碼散布與資訊提供責任的分擔。

關於「軟體清單」，葛冬梅小姐在自由軟體鑄造場電子報法律專欄曾發表過一篇介紹的專文「善用自由軟體資訊清單有效降低法律糾紛的風險」：https://www.openfoundry.org/tw/legal-column-list/8397-2011-07-22-09-56-32

您可以點閱上列連結來參考。



敬祝 順心健康、事事如意！

20111121 1845 LUCIEN C.H. LIN