前幾天一位社群朋友轉寄一篇 Allison Randal 的文章（註三）連結 給我，其中就以 Linux 為例，說明未來可能碰到的 GPL2（GNU General Public License v.2）、GPL3 相容性問題。通篇看下來，發覺，其 中所隱藏的問題還真不小！

在 GPL2 規定中，與本文所要探討問題有關的是第 9 條，該條是說 FSF 可以隨時修改或發佈新版 GPL，此時使用者再次散布程式的時候， 有著可以選擇修改版、新版或任何一版 GPL 的選擇權。選擇權內容 隨著程式授權聲明而定：若程式標明適用某一特定版本、及其後任何 一版 GPL 的話，一旦 FSF 發佈修改／新版時，使用者就有權利選擇 保持不變，或是適用修改／新版 GPL；若僅僅單純適用 GPL，卻未有 任何的標示說明這個程式適用那一特定版本 GPL 的話，使用者再次 散布程式時，可以選擇任何一版的 GPL 做為授權條款。而依照這一 條字面的意思來解釋，著作權人一旦決定採用 GPL 做為程式的授權 條款，無論如何，程式的使用者就一定有選擇適用修改版或新版 GPL 的權利。

根據這樣的規定，回到前面來談未來可能產生的 Linux 授權條款相 容性問題。但是在第一關就會遭遇困難，因為 Linux kernel 的標示 與 GPL2 規定不同。

眾所周知 Linux kernel 採用 GPL2 授權，但卻是標明「採用 GPL2」 授權，並非是「採用 GPL2 或其後任何一版本」。關於這類情況， GPL2 並未規定，FSF 網站上 GPL 的 FAQ 也沒有說明（註四），在 尚未有確實爭議案例出來之前、只能各說各話，這樣的各說各話可以 是：既然 GPL2 未規定此種情況，那麼就視為著作權人未授權，使用 者沒有選擇適用修改／新版 GPL 的權利，除非另行徵求原著作權人 的同意，否則仍沿用原特定 GPL 版本；或者是，GPL2 第 9 條的主 要目的是希望修改／新版 GPL 可以被廣為採納，但又避免徵求眾多 著作權人同意的過程費時，因此將是否採用修改／新版 GPL 的權利 交給使用者，如此可以兼俱修改／新版 GPL 被廣為採納又節省時間 精神的優點。

假設第一關困難解決，而解決的結果有二：Linux kernel 沿用 GPL2， 或者是改採用 GPL3。在採用 GPL3 的情況，目前推測起來，較不會 產生進一步的困擾，主要原因與 Linux kernel 配套運作的 GNU 套 件（GNU packages）大多為 GPL2 授權，並且為 FSF 所有、或至少 FSF 被授與有權利決定授權內容，依照 FSF 的立場，其自然會讓 GNU 套件都採用 GPL3 授權，此時 kernel 與套件授權條款一致。 若 Linux kernel 沿用 GPL2，而依照上述的推論，GNU 套件卻採用 GPL3，雙方著作權人又不願意改變心意，此時因為 GPL2 與 GPL3 內容不盡相同，極有可能會產生不相容的問題，至於會產生什麼樣 的問題，因為 GPL3 尚未完全定稿，筆者目前也不敢妄加說明。在 此，僅僅可以比較確定地說：由過去一年多各界對於 GPL3 草案的 爭論來看（註五），上述後者不相容情況發生的機率相當高。

在上述不相容情況發生的前提下，再進一步，這時候使用者應該如何 應對？對於個人使用者來說，其可以單純地自行使用 Linux kernel 與 GNU 套件，只要不要將兩者結合後一起散布給他人，將不會產生 任何問題，只是一般的個人使用者並沒有能力將 kernel 與套件結合 在一起的能力，因此 kernel 與套件授權條款不相容的現象，將對於 Linux 作業系統的使用造成一定的負面影響。而對於像 Red Hat、 SUSE 這樣的企業來說，其本來就是透過將 kernel 與套件結合在一 起販賣來牟利，在最糟糕的情況下，可能企業使用者必須自行維護一 套 GPL2 版本的 GNU 套件，因為授權條款的轉換只能向未來發生效 力，FSF可以對新發佈的 GNU 套件適用 GPL3，卻無法溯及既往改變 之前發佈套件採用 GPL2 的事實，企業可以在 GPL2 授權的 GNU 套 件基礎上自行維護、開發，不過，對於即使擁有相當財力人力的企 業來說，要維護目前規模的 GNU 套件也並非易事。

寫到這裡，似乎聽來頗危言聳聽，不過以上不少是在假設的基礎上進 行的演繹推論，因此是否真會如此發生，也尚未可知，即使發生，相 信各界也會商討出一個折衷的解決之道。此外，筆者以法律的角度思 忖，也許解決之道會在 GPL3 當中！一個很簡單的道理：FSF 自行撰 寫 GPL2 與 GPL3，其也知道 GPL2 第 9 條，因此絕對會將上述的一 些情況考量進去。因此，筆者自行判斷，也許可以從 GPL3 草案第 3 版的第 7 條看出一些端倪，這一條大意是規定，使用者可以為 GPL3 程式加上一些附加條款 (additional terms)，正在草擬的 LGPL3 ( GNU General Lesser Public License v.3) 就是以 GPL3 附加條款 的型式存在（註六），因此也許有可能透過對這一條的闡釋，GPL2 以 GPL3 附加條款的型態，與 GPL3 並存。不過，如之前提過的，這 一切還是要等 GPL3 定稿發佈，才好做進一步的研究分析，筆者也衷 心期待，定稿的 GPL3 可以對於這個極有可能發生的問題提供一個解 決的方式。

註一：GPL3 草案草擬網站。
註二：FSF、Free Software Foundation
註三：Allison Randal，GPLv3、Linux and GPLv2 Compatibility。
註四：http://www.fsf.org/licensing/licenses/gpl-faq.html#VersionTwoOrLater
註五：Linux kernel 開發社群領袖 Linus Trovalds 公開強烈抨擊 GPL3 各版草案，是個具有相當的影響力的因素。
註六：GPL3 與 LGPL3 草擬網站。

下一版的 OpenOffice.org 將會納入 Pentaho 的開放源碼商業智慧 (Business Intelligence，BI) 軟體。Pentaho 希望藉著與 Open- Office.org 社群及 Sun 的緊密合作，有助擴展其商業智慧軟體的使 用族群。

開放源碼桌面軟體套件 OpenOffice.org 是微軟私有軟體 Office 的 競爭對手，源自於 Sun 在 1999 年買下的 StarOffice。Sun 在 2000 年成立 OpenOffice.org 後，就是這個專案的主要程式碼貢獻者。

估計全球用戶超過 4 千萬的 OpenOffice.org，在各大 Linux 散佈 套件如紅帽、Novell 的 Suse Linux 與 Canonical 的 Ubuntu，皆 可發現這套開放源碼桌面軟體套件的存在。

Pentaho 行銷副總裁 Lance Walter 表示，Pentaho 的報表引擎 Pentaho Reporting 將會納入下半年即將推出的 OpenOffice.org 2.3 版中，事前 Sun 與 Pentaho 已就 OpenOffice.org 中整合商業智慧 功能，計劃了約 1 年時間。Walter 表示，這是 Pentaho 的報表引擎 第一次整合到桌面生產力套件中，預計將會擴展 Pentaho 的使用族群。

Pentaho 是在 2005 年 12 月買下開放源碼專案 JFreeReport Java 報表程式庫時，取得其報表引擎的技術，隨後加入了拖放 (drag-and- drop) 報表製作軟體並與其商業智慧平台整合。Pentaho 並於去年買 下資料探勘與預測分析專案 Weka 後，完成了旗下的商業智慧套件。 Pentaho 的市場競爭對手包括了開放源碼廠商 JasperSoft 與私有軟 體商 Cognos 及 Business Objects。

結合了 Pentaho Reporting 與 Sun 發展的新 Report Designer， OpenOffice.org 的用戶製作的報表，將可取用 OpenOffice.org Base 與各類私有與開放源碼資料庫等來源的內容。

當然 Pentaho 此舉也是希望部份 OpenOffice.org 用戶能轉而向 Pentaho 尋求更多商業智慧技術與付費的商業支援。

Ventana Research 執行長兼研究執行副總裁 Mark Smith 預料由於 微軟在 Office 2007 中加入商業智慧功能，開放源碼與私有桌面軟 體套件中會提供越來越多的商業智慧功能。開放源碼社群必須開始以 更為解決方案導向的模式運作，以便與微軟、Oracle、SAP 等公司的 解決方案對抗。

相關網址：
1.下一代 Open Office 納入商業智慧軟體
2.OpenOffice 提供商業智慧
3.OpenOffice 新動作讓開放源碼更貼進商業應用