您好.
最近看了許多貴司發表的有關opensource法務的相關文章後, 針對您所說使用open source後所產生的責任主要是發生在散佈程式時, 這裡有幾點問題想請教.

1. 如果我是拿到一個GPL的open source的文書編輯軟體, 例如open office之類的, 當我修改其source code後開發出了另一套文書編輯軟體, 就稱它my office好了. 然後我利用my office編輯產生一個文件檔案, 並散佈這文件檔給別人. 這裡要強調的是我只是散佈這文件檔, 沒有散佈my office這套軟體, 請問這樣需要連帶把my office的source code也散佈出去嗎?

2. 如果我是拿到一個GPL的open source的C語言compiler軟體, 當我修改其source code後開發出了另一套C語言compiler, 就稱它my compiler好了. 然後我用C語言自己寫一個程式, 利用my compiler編譯產生一個二進位執行檔, 並散佈這執行檔給別人. 這裡要強調的是我只是散佈這執行檔, 沒有散佈my compiler這套軟體, 請問這樣需要連帶把my compiler的source code也散佈出去嗎?

2. 承第二題, 我用C語言自己寫一個程式, 就稱這程式為程式A, 程式A有用到GPL的open source的code. 然後利用my compiler編譯產生一個二進位執行檔, 並散佈這執行檔給別人. 這裡要強調的是我只是散佈這執行檔, 沒有散佈my compiler這套軟體, 請問這樣需要連帶把my compiler和程式A的source code也散佈出去嗎?

Regards,
Justin

Hi Justin,

相關的問題我簡單分析如下：

一、關於OpenOffice及MyOffice議題的討論

1、單純散布MyOffice的文件檔≠散布MyOffice的程式碼

所以若是單純散布文件，不必然等同於散布MyOffice程式本體，自然就不會有後續需提供MyOffice程式原始碼的問題。

因為照GPL2較文意的解釋「You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following」，散布行為指的是散布程式碼的行為，不論是Object Code或是Source Code，所以若是採用較嚴格的文意解釋態度來看，要有Code Conveying才會該當程式碼的散布行為。

2、然此MyOffice文件原則上透過其他文件編輯程式亦可讀取

然而、爭議點在於，若是用其他的文書編輯程式都無法讀取這個MyOffice產生的文件的話，那散布文件本身的爭議性就會提高。例如以Gimp或是Photoshop都能產出圖片，它的格式可以是tiff、png、jpeg，使用者選用任何一種圖片瀏覽程式都可以觀看，那麼Gimp雖然是以GPL授權，並不表示Gimp產出的所有圖片都內含GPL授權的意涵；不過、若是某一個文書編輯軟體或是圖形編輯軟體，其產出的檔案格式只有原來的編輯器可以開啟，那授權方面的爭議就會升高，因為確實是有部份的自由軟體社群參與者會對這樣的規避行為有所批評。

二、利用GPL授權的MyCompiler編譯出二進位Binary File，此一Binary File原則上並不算是MyCompiler的衍生作品。

原則不算、但具體情況要看個案來判定。

例子可以舉GCC Compiler為例，GCC Compiler其中有部份的函式庫程式是以GPL2授權的，早先也有許多人就此議題討論過，爭議點就在於經GCC Compiler編譯過的檔案，會不會被認為是GPL程式的衍生作品，其實就此議題採正面看法和反面看法的人都有，採正面看法的人是認為，經GCC Compiler編譯過的程式，其實部份GPL授權的程式碼是內含到所編譯的檔案裡的，從而會開啟GPL授權程式的授權拘束性；持反面看法的人認為，所謂「編譯」就是一種「工具性的使用」，應該是GPL授權條款裡說的「單純使用GPL程式(the program using the GPL program)」，而非「衍生自GPL程式的新作品(the program based on the GPL program)」。

但是最後GCC Compiler專案的共識是，在GPL授權條件上加上一個GCC Runtime Library Exception，Justin對這個議題有興趣可以看看它的Rationale:https://www.gnu.org/licenses/gcc-exception-faq.html，結論就是這樣的使用方式不會開啟GCC Compiler內含GPL函式庫的授權拘束性。

但是並不是所有GPL Compiler的授權解讀都完全類同GCC Compiler這個專案，所以這個問題我的看法是，原則上MyCompiler編譯出來的二進位檔案並不是MyCompiler的衍生作品，但是實際狀況還是要評估MyCompiler是根據哪一個自由軟體專案所衍生出來，因為該專案或許對於GPL的授權拘束性，有著比GCC Compiler更嚴謹的解讀態度。

三、關鍵重點在於程式A是否為GPL授權程式的衍生作品，若程式A已經被認定為是GPLed的衍生著作，那麼不論經過哪一種授權狀態的編譯程式編譯，其編譯的結果都還是GPL授權的程式。

法律實務上透過「機械式自動化」的方式，將軟體專案改為另一個表現形式，這個新形式的著作權客體與轉換前相同，會被視為同一權利客體，也就是說、如果程式A有Merge到GPL的程式碼，那麼依照GPL2的規定，程式A「As a whole」整個專案再散布時只能以GPL授權條款為唯一能選擇的授權方式，就算透過MyCompiler以自動化的方式將程式A編譯為形式B的二進位執行檔，但程式B還是等同程式A為同一著作權客體，再散布時一樣僅能以GPL授權條款為唯一能選擇的授權方式。

我個人的分析約略是如此，

後續如果更有想法歡迎隨時討論。

敬祝 順心健康

20091029 1715 自由軟體鑄造場 林誠夏

針對誠夏的回應（一、關於OpenOffice及MyOffice議題的討論），我補充一個我的看法：

2、然此MyOffice文件原則上透過其他文件編輯程式亦可讀取

然而、爭議點在於，若是用其他的文書編輯程式都無法讀取這個MyOffice產生的文件的話，那散布文件本身的爭議性就會提高。例如以Gimp或是 Photoshop都能產出圖片，它的格式可以是tiff、png、jpeg，使用者選用任何一種圖片瀏覽程式都可以觀看，那麼Gimp雖然是以GPL授權，並不表示Gimp產出的所有圖片都內含GPL授權的意涵；不過、若是某一個文書編輯軟體或是圖形編輯軟體，其產出的檔案格式只有原來的編輯器可以開啟，那授權方面的爭議就會升高，因為確實是有部份的自由軟體社群參與者會對這樣的規避行為有所批評。
針對這段文字，我認為縱使社群理論上會加以批評，但實際上或許反而不會有什麼問題。

簡單的說，就是因為，只有原編輯器MyOffice才能開的檔案格式，根本無法流行起來。假設這個文件格式叫做.mod，如果想讓.mod流行，就必然得把MyOffice這個編輯器（或至少要能開啟的閱讀器，例如MyOffice Reader）給出來，因為這個程式本來是改自GPL的code，一旦將object code給出來，就必須要依GPL規定給出其source code。如此一來，MyOffice也就真正open source了。

所以我想若要做出一個MyOffice，那就一定會想辦法使其產生的檔案依照現在流行的格式，諸如.doc、.odt等等。


20091031 2029 自由軟體鑄造場 林珈宏 Richard J.H. Lin