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 自由軟體鑄造場 林誠夏