[技術專欄] CentOS 基礎設定（上）

Weithenn (http://www.weithenn.org/)／文 2011-06-25

前言

Red Hat Enterprise Linux 為 Red Hat 公司推薦使用於企業伺服器網路服務上的 Linux 發行版本，通常大多數的人會將此 Linux 發行版本簡稱為 RHEL（雖然 Red Hat 公司官方並不建議這樣簡稱）。在正常的情況下 RHEL 大約以每 18 ~ 24 個月的頻率，發佈下一版的作業系統。但是實際運作上 RHEL 作業系統版本的發行頻率，取決於 Fedora Linux 的更新。Fedora Linux 為 Red Hat 公司贊助的知名開放原始碼計畫，Red Hat 公司會將許多新技術先行導入至 Fedora Linux 發行版本中，待經過一段時間測試至穩定階段而且符合企業需求後，便會將該技術加入至下一個發行的 RHEL 版本中。每當 Fedora Linux 發行 3 個版本後大約就會發佈 1 個 RHEL 新版本

而本文所要介紹的 CentOS (Community ENTerprise Operating System) 為眾多 Linux 發行版本之一。CentOS 其源碼來自 RHEL 作業系統的開放原始碼，將其源碼重新編譯而成的，移除了無法自由使用的商標及 Red Hat 所擁有的封閉原始碼軟體。由於 CentOS Linux 與 Red Hat Enterprise Linux 具有大量相同的原始碼內容，因此也適合在需要高度穩定性的企業營運環境。

目前有些中小企業的 IT 人員為了建置預算上面的考量使用 CentOS Linux 發行版本來替代 RedHat Linux 企業版本。但是相對來說使用 CentOS Linux 發行版本除了得不到商業支援以外，當然也不包含 Red Hat 公司所擁有的封閉原始碼軟體。因此建議 IT 人員在使用 CentOS Linux 發行版本來建置企業網路服務以前，除了要先了解所使用的硬體伺服器是否支援 CentOS Linux 之外，更要了解所架設的商業服務是否會使用到 Red Hat 公司封閉原始碼軟體。

CentOS Linux 作業系統版本命名規則分為二個部份，分別是主要版本及次要版本來進行版本表示。其中主要及次要版本號碼，則是相對應於紅帽公司所發行的 RHEL 作業系統主要版本與更新版本號碼，例如 CentOS 5.5 版本便是相對應於 RHEL 5 update 5 版本。

實作環境

* CentOS 5.5 32bit (Kernel 2.6.18-194.el5)

建立一般使用者帳號

為了減少不必要的篇幅內容，本文並不會說明如何從頭開始安裝 CentOS Linux 作業系統，建議有興趣的讀者可以參考官方使用者手冊 CentOS-5 Documentation，相信具備基本知識的使用者一定能夠順利無誤將 CentOS  作業系統安裝起來。筆者只有一點安裝建議，那就是在安裝過程中，/var 此掛載點的使用空間不要給太少，以免後續維護時發生問題。原因在於 /var 掛載點除了為預設所有記錄檔存放處以外，更重要的是當後續系統執行更新相關套件時，其暫存的資料便是存放於 /var/cache/yum 內。因此 /var 掛載點空間太小將可能導致套件更新失敗的情況發生。

在安裝 CentOS 作業系統過程中會要求您順便設定 root 管理者帳號，作業系統安裝完成後請使用 root 管理者帳號登入系統。Linux 系統管理者應該具備如同管理 Microsoft Windows 主機時同樣的作業系統安全性觀念，也就是要先建立一般使用者帳號來登入系統進行操作，待需要執行的動作需要提升至管理者權限時，才著手轉換將權限提升。因此持同樣的安全觀念當您首次登入 CentOS 作業系統後，建議您先為管理者建立一般使用者帳號後，再將該使用者帳號加入管理者群組當中。下列操作動作為先建立使用者家目錄資料夾，因為筆者習慣將使用者家目錄都集中於一個目錄內以便後續方便管理（預設使用者家目錄為存放至 /home 下）之後透過指令 adduser 建立一般使用者帳號 weithenn（-d 參數為指定該使用者家目錄位置），接著使用指令 passwd 設定使用者密碼，最後則是設定將該使用者加入管理者群組 wheel 當中。

▲ 圖1 新增使用者帳號、設定使用者密碼並加入 wheel 群組

設定網路功能

建立好使用者帳號後接下來便是設定 CentOS 的網路功能，在本文設定中網路功能是以設定固定 IP 位址來進行說明。可以透過二種方式設定固定 IP 位址，一為使用指令 system-config-network 來進行互動設定，另外一種方式則為手動將固定 IP 位址、網路遮罩等相關資訊寫入 “ifcfg-eth0” 網卡設定檔中，而預設閘道及主機名稱則是寫入 “network” 設定檔中，最後則是將 DNS 名稱解析資訊寫入 “resolve.conf” 設定檔中。下列操作步驟先以 system-config-network 指令進行互動設定，之後再解釋如何手動將網路資訊寫入設定檔的方式：

1. 執行 system-config-network指令使系統進入互動設定視窗中，如圖2
2. 選擇【Edit Devices】 後此時會顯示安裝於此主機的網路卡清單，本例為選擇唯一的一張網路卡【eth0 （eth0） – VMware VMXNET3 Ethernet Controller】，如圖3
3. 將「Use DHCP」勾選項目取消並且將固定 IP 位址、網路遮罩、預設閘道等資訊填入後按下【OK】（如圖4）
4. 此時畫面回到剛才選擇網卡的視窗（以便您要設定多片網路卡設定），接著按下【Save】回到原始互動設定視窗中
5. 接著選擇【Edit DNS configuration】來進入設定 DNS 視窗，請填入主機名稱、DNS 伺服器 IP 位址等資訊後按下【OK】，如圖5
6. 最後則是按下【Save&Quit】確定儲存剛才的設定後離開互動設定視窗

▲ 圖2 使用指令 system-config-network 進入互動設定視窗

▲ 圖3 選擇要設定網路資訊的實體網路卡，此例為 eth0

▲ 圖4 設定固定 IP 位址、網路遮罩、預設閘道等資訊

▲ 圖5 設定主機名稱及 DNS 名稱解析資訊

透過上述互動設定將網路資訊設定完成後,　作業系統會將相關網路設定值寫入相對應的設定檔中，例如固定 IP 位址、網路遮罩、預設閘道資訊寫入至 “/etc/sysconfig/network-scripts/ifcfg-eth0” 網卡設定檔中，而主機名稱則寫入 “/etc/sysconfig/network” 設定檔內，而 DNS 名稱解析的網路資訊則是寫入 “/etc/resolv.conf” 設定檔內。筆者建議若您的主機安裝多片網路卡時，請將預設閘道資訊寫入至 “/etc/sysconfig/network” 設定檔內為比較洽當的設定。

所以我們可以在互動設定完畢後，查看相關網路設定檔內容時可以看到相關網路資訊均已寫入。因此您可以依個人喜好來決定要如何設定網路資訊至 CentOS 作業系統中，看您是要使用指令 system-config-network 以互動方式來設定網路資訊，或者將相關網路設定值寫入相關設定檔內也是可行的方法。就筆者個人習慣來說，會使用互動設定來設定相關資訊，並且於設定完成後查看相關設定檔內容，確定無誤即可（可以省去記憶相關設定檔內容中參數名稱）。

▲ 圖6 查看網路設定檔及 DNS 名稱解析設定檔內容

當上述設定完成後可能會發現 CentOS 主機仍然無法連上網際網路。雖然透過互動設定已經設定好相關網路資訊，但作業系統目前仍未套用變更相關設定（例如套用預設閘道設定值）。建議您可以執行指令 reboot，重新啟動主機來自動套用剛才設定的相關網路資訊。

當您將 CentOS 主機重新啟動完成之後，您可以使用 ping 指令來判斷主機是否能順利連上網際網路及進行名稱解析的動作，或者藉此判斷此台主機的網路通訊是卡在哪個環節上以便除錯。

▲ 圖7 測試主機能否順利與網際網路主機進行通訊

修改 SELinux 安全增強機制

Linux 作業系統從核心 2.6 版本開始預設會自動載入安全增強機制 SELinux ( Security-Enhanced Linux) 核心模組。SELinux 是由美國國家安全局 NSA (National Security Agency) 所開發，並且在 2000 年 12 月時將此核心模組發行給開放原始碼的開發社群，以便有效加強 Linux 整體安全性。

SELinux 為基於保護原則、作業系統中檔案結構及檔案權限的完整性原則所設計，此完整性原則可以有效針對入侵行為，以及企圖跨越系統安全架構等設計不良的應用程式對作業系統所造成的破壞，因此可以提供更安全的強制存取控制架構，來與作業系統的核心和主要子系統協同運作。在這樣的架構下相關的服務 (Daemon) 只能存取屬於該服務帳號所能存取的資料夾及檔案權限，若是超過所能存取的權限範圍則 SELinux 便會阻擋該服務的存取行為。所以若主機所架設的服務出現安全性漏洞導致被攻擊時 SELinux 能夠有效將攻擊所造成的損失降到最低。

簡單來說啟用了 SELinux 安全增強機制後的 Linux 作業系統，其檔案權限便不僅僅是傳統上的三種權限－讀取 r、寫入 w、執行 x－，及身份－擁有者 Owner、群組 Group、其它人 Others，而是整個主機內的檔案系統，將會套用更細微的權限及身份設定並且具有完整性架構。然而也因為 SELinux 安全增強機制及完整性原則，常常會造成 Linux 初學者因為不了解檔案系統及相關概念，進而導致設定相關網路服務時，因為違反了 SELinux 安全機制或者完整性原則，而導致網路服務無法啟動，或者無法存取系統資料（因為被 SELinux 安全機制給阻擋住了）。因此筆者通常會建議初學者可以先將此增強安全機制設定為警告通知，或者暫時關閉。等以後對於 CentOS 作業系統有更深的認識後再將此功能啟用。當然這樣的情況是自行測試或學習時，使用者若是用於企業營運時則強烈建議一定要開啟 SELinux 安全增強機制來提升及保護主機安全性。

要修改 SELinux 安全增強機制的設定，您可以透過修改 “/etc/sysconfig/selinux” 設定檔，或者使用指令 system-config-securitylevel 進入互動設定視窗進行設定之後再將主機重新啟動即可套用變更，SELinux 安全增強機制共有三種運作模式說明如下：

1.        enforcing：啟動模式，SELinux 安全增強機制啟動將會阻擋不當的存取行為。
2.        permissive：寬容模式，當系統發生違反 SELinux 安全增強機制時僅僅顯示警告訊息而不會實際進行阻擋的動作，此模式很適合有心學習 SELinux 機制的學習者。
3.        disabled：禁用模式，完全將 SELinux 安全增強機制禁用。

筆者建議您可以將設定值修改為寬容模式 (permissive)，因為當您的操作行為違反 SELinux 安全增強機制時會顯示警告通知您，因此您可以有效學習到哪些操作或者哪些動作是會被 SELinux 阻擋哪些不會，這樣可以讓您日後真正開啟 SELinux 安全增強機制時，不致被卡住並且早日提升您所管理的主機系統整體安全性。您可以透過 sestatus 指令來判斷目前主機中 SELinux 的運作模式及狀態，此設定值變更後必須要將主機重新啟動才能套用變更，當重新啟動後請記得再次使用 sestatus 指令以便確認您的修改正確有效。

▲ 圖8 修改 SELinux 設定檔以變更運作模式

▲ 圖9 互動設定修改 SELinux 運作模式

禁止 root 管理帳號遠端登入

在預設的情況下您可以直接使用 root 管理帳號來遠端登入 Linux 作業系統進行管理，然而在管理作業系統上通常安全性與便利性是相對的二個拉扯點。當您所管理的作業系統其操作便利性愈高則安全性通常會相對的降低。筆者在此建議您關閉 Linux 預設允許 root 管理者帳號可以遠端登入管理系統，原因有三：

1.    首先是您的主機將增加了被入侵的機會。在管理者帳號已知情形下，剩下就是嘗試登入密碼了，如此一來很容易遭受暴力猜測密碼攻擊。
2.    當一台主機有眾多管理者時大家皆使用 root 管理者帳號登入系統進行管理動作，則誰修改了某個檔案內容或執行了哪些動作均無法稽核，因為記錄的資料都是 root。
3.    最後則是直接使用 root 管理者帳號登入系統進行管理，若是在操作過程中不慎下錯指令時有極大的可能會把系統給毀掉。例如原本是想刪除根目錄下的 test 資料夾 rm –rf /test 若不慎在操作時不小心多個空格 rm –rf / test，則對於作業系統來說是要刪除根目錄 （/） 及目前所在的 test 資料夾。

要將 CentOS 主機預設允許 root 管理者帳號遠端登入的功能關閉，可以透過修改 “sshd_config” 設定檔後再重新載入 SSH 服務即可套用變更，套用完成後您可以測試是否無法使用 root 管理帳號遠端登入主機以便確定修改是否生效。

▲ 圖10 修改 SSH 設定檔及重新載入 SSH 服務

讀者可能覺得很奇怪，遠端登入主機時輸入帳號後怎麼要等很久才能輸入密碼？會有這樣的狀況發生是因為 CentOS 在啟動 SSH 服務時預設會配合使用名稱解析所導致，若您主機運作的網路環境中名稱解析服務已經運作正常則不會有此問題發生。若發生這樣的問題請檢查 DNS 名稱解析中反向解析對於此主機的解析情況，若此台主機所在的網路環境中並沒有反向名稱解析的機制，您可取消 SSH 服務中預設會使用到名稱解析的動作即可解決此一問題。

▲ 圖11 取消 SSH 服務使用名稱解析服務

結語

本文進行至此已經建立好一般使用者帳號並將其加入管理者群組，並且設定好 CentOS 主機的網路連通資訊（固定 IP 位址、網路遮罩、預設閘道、DNS 名稱解析、主機名稱），並且確認主機可連結至網際網路上的機器，其網路功能運作無誤。再來則是將 SELinux 安全增加機制設定為寬容或禁用模式，以免在您剛開始學習 CentOS 作業系統時遭遇困難，最後則是關閉 root 管理者帳號，關閉遠端登入系統的權限以及關閉 SSH 服務反向解析的機制。此時的 CentOS 主機已經具備網路連通能力而主機的管理者也可以遠端管理主機了。

在下一篇基礎設定文章中，首先會探討如何透過 RunLevel 建立良好的使用者操作 Shell 環境。接下來則是建立良好的編輯檔案環境及設定 sudo 來限制及記錄管理者帳號 root 的使用記錄。最後則是談到設定套件管理工具 YUM ，將下載套件的來源指向至台灣本地鏡像網站，以加快軟體套件下載時間。

[源碼密技] 用自由軟體 Plone 來架設網站(7)一版型調整

marr／文 2011-06-28

在前篇文章裡，透過 ZMI 和網頁介面，我們已經完成不少佈景主題的調整，有了這些知識和經驗，接下來，我們要在檔案系統裡，練習程式碼的調整方式，認識更多佈景主題的相關細節，包括 main_template.pt 的語法細節，Viewlet Manager 的調整方法，和 Viewlet 的註冊方式。

main_template.pt 是 Plone 的核心樣版檔案，它負責決定佈景主題的 layout 位置，像是表頁區塊、表尾區塊、主要內容區塊等，在 Plone 3.0 之後，視覺元件的再利用工作，不再採用 METAL 巨集的方法，而是改用 Viewlet Manager 和 Viewlet 的方式。本文將示範在檔案系統裡，管理 Viewlet Manager 的技巧。

預設的佈景主題

對一般使用者而言，Plone 4.x 的預設佈景主題是 Sunburst，不過，從開發者的角度來看，所有佈景主題的程式碼，預設是以一個稱為 Plone Default 的佈景主題為基礎，你可以進入 buildout-cache/eggs 目錄，在 Products/CMFPlone/profiles/default/viewlets.xml 找到 skinname="Plone Default" 的設定值，在 Products/CMFPlone/profiles/default/skins.xml 找到 default_skin="Plone Default" 和 skin-path name="Plone Default" 的設定值。


▲ 圖1 Plone Default 的 viewlets.xml 內容

Sunburst 就是以 Plone Default 為基礎，加上自製的 CSS 檔案而成，你可以在 plonetheme/sunburst/profiles/default/skins.xml 找到 skin-path name="Sunburst Theme" based-on="Plone Default" 的設定值。


▲ 圖2 Sunburst 的 skins.xml 內容

除了 Sunburst 之外，還有一個稱為 Plone Classic 的佈景主題，也是以 Plone Default 為基礎，它的目錄在 plonetheme/classic 裡。

利用 Plone Default 的程式碼為基礎，是維護升級相容度的慣例作法，這種作法足以應付多數情況的需求。

建立模組專案

佈景主題是 Plone 的模組專案，同樣可以透過 paster 來建立，不過，我們改用 zopeskel 程式，它是包了糖衣的 paster 程式，使用 plone3_theme 參數，再接上 plonetheme.mytheme 專案名稱，就能建立新的模組，如圖3 所示。


▲ 圖3 使用 zopeskel 建立 plone3_theme 專案

接著會出現數個問題，我們只要指定 Skin Name 就行，以填寫 MyTheme 為例，安裝模組後，在 ZMI 的 portal_skins 裡，會看得到 MyTheme 的 Skin 選項。最簡化的情況下，其餘問題都按 Enter 就行，如圖4 所示。


▲ 圖4 模組專案問題的回覆範例

想要安裝啟用 plonetheme.mytheme，把它寫進 buildout.cfg 檔案，如圖5 所示。


▲ 圖5 plonetheme.mytheme 的 buildout.cfg 範例

執行 bin/buildout 之後，可以在 Site Setup 看到這個模組，代表已經可以啟用它，如圖6 所示。


▲ 圖6 plonetheme.mytheme 成為可安裝模組

不過，剛建立的 plonetheme.mytheme 非常單調，若此時啟用它，反而會弄亂佈景主題，如果遇到弄亂的情況，可以到 Theme settings 裡，手動指定 Default theme 為 Sunburst Theme 後，就能恢復。

視覺元件技術項目

Plone 視覺元件架構裡，最底層的技術項目，彼此之間的關連性，可以用圖7 來表示。


▲ 圖7 視覺元件的關連示意

對照 plone3_theme 專案的檔案目錄樹狀圖，更容易了解上述技術項目的關係，如圖8 所示。我們把 plonetheme.mytheme.egg-info、setup.cfg、setup.py 之類的檔案從樹狀圖裡移除，因為它們屬於 Python egg 的設定內容，暫時不需要理會。


▲ 圖8 plone3_theme 專案的檔案系統樹狀圖

首先要關注的，是 plonetheme/mytheme 目錄裡的 configure.zcml 檔案，它註冊了模組的起始資訊，包括通知系統導入其他 ZCML 檔案或目錄，以＜include package=".browser /＞為例，當中的 . （點符號） 代表和 configure.zcml 同樣位置的目錄，如圖9 所示。


▲ 圖9 plonetheme.mytheme/configure.zcml 範例

常見的佈景主題修改工作，例如調整 Viewlet 的顯示與否、順序位置等，只需要修改 Viewlet Manager 的設定值，更複雜的調整工作，例如自訂型別的顯示方式，則需要註冊新的 Viewlet Manager、Viewlet、Browser View 等，接著，我們將示範修改的方法。

Viewlet Manager 管理方式

從 Zope 3.2 開始，content provider 是產生網頁內容的元件，通常以 Page Template 型式存在，在前文裡，我們介紹 main_template 是控制 Viewlet Manager 的重要檔案，它的預設位置在 Products/CMFPlone/skins/plone_templates/main_template.pt，這個檔案只呼叫 Viewlet Manager，再由 Viewlet Manager 管理 Viewlet 的細節，包括註冊、順序、顯示方式等。

以檔案裡＜div tal:replace="structure provider:plone.portaltop" /＞為例，provider 表示式是配合 Zope 3 而生的新語法，用來呼叫 content provider，像 Viewlet 和 Viewlet Manager 是兩個常見的 content provider。

所有的 Viewlet Manager 和 Viewlet 定義在 plone.app.layout 模組的 viewlets 目錄裡，在 viewlets/configure.zcml 檔案可以找到定義值，範例如圖10 所示。


▲ 圖10 Viewlet Manager 的定義範例

範例裡的 IPortalHeader 是一個 marker interface，實作這個介面的 Viewlet Manager 名稱是 plone.portalheader，它將管理 plone.skip_links、plone.searchbox、plone.logo、plone.global_sections、plone.personal_bar 這幾個 Viewlet，範例如圖11 所示。


▲ 圖11 Viewlet 的定義範例

範例裡的＜browser:viewlet /＞使用 manager=".interfaces.IPortalHeader" 的話，就是歸屬 plone.portalheader 的 Viewlet。以 plone.logo 這個 Viewlet 為例，它的 Python Class 定義在 viewlets/common.py 檔案，內容如圖12 所示。


▲ 圖12 plone.logo 的 Python Class 範例

範例裡的 index = ViewPageTemplateFile('logo.pt') 代表 LogoViewlet 會呼叫 logo.pt 檔案，回傳 Page Template 的執行結果，其程式碼內容如圖13 所示。


▲ 圖13 logo.pt 的 Page Template 內容

範例裡的 tal:attributes="href view/navigation_root_url" 代表 href 的屬性值，將指定為 view/navigation_root_url，其中的 view 代表 plone.logo 的執行結果，同樣的道理，tal:replace="structure view/logo_tag" 也是要讀取另一個 plone.logo 的執行結果，它的程式碼在圖12 裡看得到。

找不到 navigation_root_url 的程式碼嗎? 由於 LogoViewlet 是繼承 ViewletBase 的 Python Class，這些變數值在 ViewletBase 裡已經定義好，同時，你也會看到 ViewletBase 實作了 zope.viewlet.interfaces.IViewlet 介面，如圖14 所示。


▲ 圖14 ViewletBase 的 Python Class 內容

值得一提的是，除了呼叫 Python Class 的方式，Viewlet 還可以直接呼叫 Page Template 的內容，使用 template="portal_header.pt" 之類的方式，如圖15 所示。


▲ 圖15 Viewlet 呼叫 Page Template 的定義範例

調整 Viewlet 的順序和顯示

我們在圖10 看到 Viewlet Manager 是 OrderedViewletManager 的 instance，這代表它所管理的 Viewlet 可以按照順序存取，預設的順序值記錄在 Products/CMFPlone/profiles/default/viewlets.xml 檔案裡，如圖16 所示。


▲ 圖16 Plone Default 的 viewlets.xml 範例

那麼，如何在我們的 plonetheme.mytheme 模組，調整 Viewlet 在 Viewlet Manager 裡的順序呢？第一種方式，是全數列舉法，直接複製 Products/CMFPlone/profiles/default/viewlets.xml 內容，放到 plonetheme/mytheme/profiles/default/viewlets.xml 裡，最後再按需要進行編輯。

第二種方式，則是部份列舉法，利用 based-on="Plone Default" 語法，取得 Plone Default 的順序值後，再個別指定 Viewlet 的順序，例如想把 plone.logo 移到 plone.portalheader 的最上方，範例如圖17 所示。


▲ 圖17 調整 plone.logo 順序的設定範例

想要將 plone.searchbox 隱藏起來，可以用＜hidden /＞語法，範例如圖18 所示。


▲ 圖18 隱藏 plone.searchbox 的設定範例

日後需要再顯示 plone.searchbox 的話，可以在＜hidden /＞裡使用 remove 語法，範例如圖19 所示。


▲ 圖19 重新顯示 plone.searchbox 的設定範例

新增 Viewlet

假設我們想在 plonetheme.mytheme 模組，新增一個 Viewlet，併在 plone.portalfooter Viewlet Manager 裡，顯示貢獻者的資訊。仿照已知的運作原理，首先，可以在 browser/viewlets.py 檔案裡建立一個 Python Class，並配合一個 viewlet.pt 檔案來顯示 Page Template 內容，如圖20 所示。


▲ 圖20 自製 Viewlet 的 Python Class 範例

viewlet.pt 的程式碼內容，利用 tal:content="view/designer" 來顯示 designer 的變數資訊，除了 i18n 語法待日後介紹外，其餘都是單純的 HTML 內容，如圖21 所示。 


▲ 圖21 自製 Viewlet 的 Page Template 範例

接著，在 plonetheme/mytheme/browser/configure.zcml 註冊新的 Viewlet，例如使用 mytheme.credits 當作名稱，如圖22 所示。


▲ 圖22 註冊自製的 Viewlet 範例

在 plonetheme/mytheme/profiles/default/viewlets.xml 指定 Viewlet 的順序，例如放在 plone.colophon 之後，如圖23 所示。


▲ 圖23 指定自製 Viewlet 順序的範例

結論

Viewlet 和 Viewlet Manager 把 Plone 的視覺元件，有效地組織起來，在本文裡，我們練習幾個常見的調整工作，在檔案系統裡直接管理程式碼，包括註冊 Viewlet、顯示或隱藏 Viewlet。認識視覺元件的運作原理後，透過這些管理工具和調整技巧，我們可以控制佈景主題的每一項細節。值得一提的是，之前範例裡出現 i18n 或 locales 的設定值，都跟語系在地化工作有關，將在日後的篇幅介紹。

想要建立佈景主題，除了上述的傳統方式外，Plone 4.1 預計將導入新的架構方法，讓我們直接利用靜態 HTML 網頁，加上規則定義，即時產生內容與佈景主題整合後的網頁。這項新進展，可以提供另一條途徑，吸引更多網頁設計人員參與 Plone 的開發。

[法律專欄] 淺談著作財產權讓與適用於 copyleft 開源軟體所產生的問題及因應之道

林懿萱／文 2011-06-23

一般公司在採購軟體、聘僱員工或者是與其他公司共同研發技術等事務的過程中，常會涉及軟體著作財產權的讓與。傳統上，著作財產權讓與多半由雙方經過協商讓與細節、達成合意、及簽訂讓與契約的程序來達成。但 copyleft 性質的開源軟體，其要求衍生著作的著作人／散布人也必須採取同樣的授權模式，才能夠進行該衍生著作的散布、流通與修改（註一）。這樣的開源軟體若套用傳統的著作財產權讓與模式，將會遇到窒礙難行的問題，甚至可能無法達到原本欲取得軟體著作財產權以達到的商業利用目的。因此，本文以下將就這些相關問題淺析之。

當一家公司試圖以傳統對著作財產權的想法來進行著作財產權讓與的交易，通常會經過以下過程：(1) 讓與人及受讓人雙方針對規範到軟體的條款進行協商，以及 (2) 要求權利的轉讓（註二）。然而，前述兩點套用在開源軟體上，會遇到困難，甚至不可行，原因在於：

一、開放源碼授權條款無法被個別協商

當兩家公司欲訂定著作財產權讓與契約，通常會由其中一方的法務人員先提出契約草案，另一方收到後若對合約內容有意見，則會回提其修改版本給對方。若兩方對合約內容一直無法達成合意，則會有好幾輪來回討論修改，直到協商出雙方都同意的條款內容為止。然而，這樣的模式卻無法套用在開源軟體上，一來因為開源軟體多由眾人參與開發的特性，所開發出的程式著作財產權分歸不同的人所有，要進行著作財產權讓與交易，很難有唯一對談的窗口（註三）；另一方面，即便找到可洽談著作財產權讓與的對象（暫且稱某甲），也因為由某甲撰寫的程式、或某甲擁有程式著作財產權的部分，可能只佔整個軟體開發專案的一小部分，某甲最多只可對其撰寫或擁有著作財產權的程式部分擁有決定權，由其他人撰寫的程式著作財產權既不歸屬某甲，則當然不可能全由某甲與買方協商整個軟體專案的權利讓與。再者，任何授權條款都必須經過開放源碼促進會 (Open Source Initiative, OSI) 的嚴格審核（註四），才被認可為「開放源碼授權條款 (Open Source License)」，也因此經 OSI 認證過的開放源碼授權條款內容，並不能被使用人自行修改，或者說，一經修改，就不得再自稱此份條款是 OSI 認證通過的「開放源碼授權條款」了（註五）。

二、copyleft 性質的開源軟體專案不適合成為聘僱契約的標的

當一家公司所購買的不是商品，而是勞務，譬如公司聘僱員工，在勞動契約書中要求，員工受雇期間職務上完成的著作，其著作財產權歸公司所有，這樣的約定內容，尚屬合理（註六）；而在出資聘人的情況，若出資人於合約中要求受聘人其完成著作，以出資人為著作人，亦算於法有據（註七）。然而如前所述，開源軟體專案具有多人參與開發及後續修改的特性，一家公司若想透過聘僱或出資的方式，要求受雇人或受聘人其撰寫的程式著作財產權歸屬該公司，然後進一步再取得整個軟體專案的著作財產權，並不可行，一來因為整個軟體專案可能有數十、數百、甚至更多的程式撰寫者參與開發，要和所有參與專案開發者皆成立委聘關係，實際上幾乎不可能；再者，copyleft 性質的開放源碼授權條款多要求其適用軟體或衍生著作，必須能夠自由再散布，且不得以直接收取軟體授權金 (royalty) 的方式進行營利。所以，既不得限制他人販賣或散布此一開放源碼軟體，亦不得收取授權金，這麼一來，對公司來說，透過聘僱或出資的方式試圖取得開源軟體著作財產權的實質意義將大幅降低。

三、取得開源軟體時多難以令其散布者直接提供擔保

由於我國現行著作權制度並不需要登記，自著作完成起即自動受到法律的保護（註八），因此，為確保讓與人確實為該著作的創作人或權利人，以電腦程式為例，在傳統電腦軟體的著作財產權讓與契約中，常見要求讓與人保證該電腦軟體的著作財產權確實為其所有，並有權為該軟體的移轉，且具文擔保該程式的撰寫未侵害任何第三人的權利（註九）。這樣的擔保責任在開源軟體上很難實現，因為開放源碼授權條款既要求授權人不得收取授權金，相對的也就免除授權人對被授權人提供擔保的責任，這些免責的範圍亦包含不侵權保證在內。而雖然近年重新修編的開源軟體授權條款，以 GPL-3.0 為例，有限度的加上額外添附條款 (additional term)，讓商業散布者可以自行提高所散布開源軟體的擔保責任，以利其承接商業營利的業務，但目前此種由上游廠商提供額外擔保的利用方式仍未普及，大部份的情況還是軟體元件的承包廠商以無償的方式取得開源專案，經過客製化修改加工之後再散布予下游廠商，這樣的程式取得過程，多難以令承包廠商能具文提供擔保予下游廠商來進行權利讓予。

四、開源軟體後續散布時並不禁止商業利用

公司透過著作財產權讓與契約的簽訂，目的在獨佔著作的利用權，以增強自身在同業間的競爭力。然而，以 copyleft 性質之開源軟體而論，其本身並不禁止商業利用、且要求在散布程式時必須提供原始碼的特性，將使得公司無法藉著傳統著作財產權讓與，以取得開源軟體完整著作財產權的方式，達到強化己身競爭力的目的。因為程式一旦經產品販售的手段散布出去，則相關的程式原始碼受到授權條款的拘束也必須一併提供，而後續其他商業公司，便可以將這些開源軟體專案的程式碼加值至自身的產品裡，這將導致第一家散布公司的產品競爭力相對地降低，而原則上，只要後續這些商業公司完全遵守該條款的各項義務性規定，就不會去侵犯到第一家散布公司的相關權利。

承上所述，開源軟體雖不允許收取授權金，但仍可收取其他相關服務費用，且開源軟體契約授予被授權人的是非專屬 (non-exclusive) 的權利，因此若一公司使用到開源軟體，付費買到的多是改進程式、除錯的服務，而不是買到該程式的著作財產權。此外，開源軟體由多人參與開發，即便透過簽訂委託開發程式契約的方式，取得一部分程式的著作財產權，也會因為這一部分程式可能佔整體軟體開發專案很小的比例，而沒有太大意義，並且若封閉這部分的程式，不再散佈出去提供大眾自由利用，將會因為違反許多 copyleft 性質的開放源碼授權條款，所取得的被授權人權利亦可能遭到終止，而後便不得再繼續利用此一開源軟體。

本文以為，在面對開源軟體時，應改變傳統終局地買斷軟體著作財產權的思維，以新的眼光認識開源軟體，現行有不少透過開源軟體社群來維護自家產品程式碼的商業公司，就是最佳的例證。這些公司聘用員工來積極參與產品相關的開源軟體社群開發工作，並且將員工所撰寫的程式碼，提交到這些開源軟體社群中，促使社群開發者共同維護這產品相關的程式碼，例如除錯、增進效能等等，而當產品升級時，商業公司可以在略加修改之後，就直接利用這些社群所維護的程式碼。因此，在面對具有 copyleft 性質開源軟體的時候，若能坦然接受其專有的特性，跳脫傳統著作財產權讓與的思維來加以利用，例如：改以支付程式開發者服務費用，或直接參與社群開發等等的方式，就可以安心地站在巨人的肩膀上享受前人所共同開發出的程式成果，讓公司的營利目標與開源軟體社群的整體發展產生良性的互動循環。

註一：關於 copyleft 的定義，請參見 http://www.openfoundry.org/tw/glossary/736-copyleft，與專文：葛冬梅，泛談 copyleft 機制與創用 CC 的「相同方式分享」授權要素，http://www.openfoundry.org/tw/legal-column-list/2051--copyleft--cc-（最後瀏覽日：06/16/2011）。

註二：http://blogs.computerworlduk.com/simon-says/2011/02/open-source-procurement-copyrights/index.htm（最後瀏覽日：06/15/2011）。

註三：同前註。

註四：OSI為一非營利組織，開放源碼界著名的「開放源碼定義」(Open Source Definition, OSD) 即是由其維護。OSI 對授權條款的審查程序包含：審核申請 OSI 認證的授權條款是否符合開放源碼定義、是否已有內容相同或類似的授權條款、是否具存在實益，並給予該授權條款適當的分類等，詳參 OSI 網站 "About the Open Source Initiative" (http://opensource.org/about) 及 "The License Review Process" (http://opensource.org/approval) 之說明（最後瀏覽日：06/16/2011）。

註五：前揭註二。

註六：我國著作權法第 11 條規定，受雇人於職務上完成之著作，以該受雇人為著作人。但契約約定以雇用人為著作人者，從其約定。

註七：我國著作權法第 12 條規定，出資聘請他人完成之著作，以該受聘人為著作人。但契約約定以出資人為著作人者，從其約定。

註八：我國著作權法第 10 條規定，著作人於著作完成時享有著作權。

註九：劉承慶 (2006)。《涉外合約與智慧財產權系列之三－智慧財產權的讓與及授權（上）》，載於外貿協會專欄網站： http://www.is-law.com/old/OurDocuments/IP0012MA.pdf（最後瀏覽日：06/16/2011）。

[自由專欄] 創用CC的常見誤解：誰該使用「非商業」(non-commercial) 條款？

洪朝貴／文 2011-06-22

◎ 本篇文章傳達筆者意見，不代表自由軟體鑄造場電子報立場，回覆意見請見部落格原文網址：http://ckhung0.blogspot.com/2011/05/cc-non-commercial.html。

發現很多朋友對創用CC的 Non-Commercial (NC) 條款有誤解。NC 的效果，是「保障自己將作品商業化的壟斷權」，而不是「讓更多人可以免費閱聽我的作品」。如果您自己本身從來就不打算將作品商業化，那麼建議不要在作品上加上 NC 條款。

如果作者本身從來就不打算將自己的作品拿去賣錢，那麼 NC 條款所達到的效果就是：這份作品永遠都只能存活在金錢經濟體制之外。（以網路時代資訊汰舊換新的標準來看，目前 copyright 所保護的時限，就等於是永遠。）比方您畫了一張圖，用 cc-by-nc 授權，被我拿來當做部落格文章的插圖。有一天我突然想將自己部落格文章結集成冊出書，這時就必須捨棄這張圖，另外換一張寬鬆授權的圖。

有人認為：「NC 條款的用意，是希望任何人都可以免費欣賞我的作品。我樂意免費分享；不希望轉了幾手之後，別人反而必須付費才能看到。」不幸地是，加了 NC 之後，實際的效果卻只是讓作品更不容易轉手（如上例，作品失去了進入商業市場的機會）「可以免費欣賞作品」的人口並未因此增加，但「願意付費欣賞作品」的人卻失去了機會。

NC 條款最大的意義是保障作者的壟斷權：當作者有一天決定將他自己的作品拿去賣錢的時候，可以確保沒有其他人會賣相同的商品與之競爭。想靠作品賺錢的人，才應該考慮採用 NC 條款。NC 是拿來掃除賺錢競爭對手用的，而不是拿來表明自己不屑銅臭用的。

聽說很多中小學老師對自己的作品施以 NC 條款，是因為配合中小學「不鼓勵老師從事商業行為」的文化。但如果我是縣市教育局長，我希望中小學老師不要從事商業行為，那麼我更會要求大家放棄自己的商業壟斷權，也就是不要加上 NC 條款。

換個方式說：如果數學定理也受到智慧財產權保護（就像「尺規文明」寓言裡面的世界一樣），如果畢達哥拉斯當初發明畢氏定理的時候加上 NC 條款，那麼將會有更多人受惠，或是更少人受惠呢？

再換個方式說：如果您認同 BSD 或 X11 類型的自由軟體授權，那麼您應該會傾向採用 CC-BY 釋放您的作品；如果您認同 GPL 類型的自由軟體授權，那麼您應該會傾向採用 CC-BY-SA 釋放您的作品。自由軟體並不反對商業行為；事實上，軟體授權若含有反商業化條款的，就不能算是自由授權，因為這樣就不夠自由。文字創作領域也有很好的例子：就像自由軟體（而不像共享軟體）一樣，維基百科從一開始就預期它的內容將來有可能被拿去商業化。所以貢獻到維基百科的圖文，必須以 CC-BY 或 CC-BY-SA 相容的方式授權。如果您認同維基百科，請考慮模仿其授權方式釋放您的作品。

另一方面，如果您的圖文影音作品加了 NC 條款，那就表示您對軟體的價值觀可能會比較接近共享軟體 (shareware) 而不是自由軟體。當然，兩種價值觀都符合網路世界的現實（「禁止拷貝是沒有用的」）。從個人的角度來看，要不要採用 NC 條款，是個人價值觀的選擇，並沒有誰對誰錯。不過，從社會整體的角度來看，「放棄商業壟斷權」的自由軟體與維基百科，顯然比「禁止他人商業使用」的共享軟體要來的成功很多。如果當初維基百科的授權加上 NC 條款，或是 Linux 核心的授權或 Firefox 的授權加上「禁止商業使用」條款，那麼恐怕今天我們就沒有機會看到維基百科挑戰大英百科、Android 手機挑戰 iPhone、Firefox 挑戰 IE。

事實上有人更進一步認為，創用 CC 應該只留下三種授權：CC-BY, CC-BY-SA, CC-BY-NC；其他授權的實用性不高，只會增加困擾。詳見：Confusion and Complexity: High time to prune the Creative Commons licenses?

也許 NC 條款應該改名為「保留商業壟斷權」條款，大家在使用時，更不容易會錯意、更能夠正確反映自己的意願及對世界未來的願景。

[接案／工作] 自由軟體鑄造場誠徵-網站程式開發工程師

OpenFoundry 開發團隊／文 2011-05-02

我們在尋找 OpenFoundry 專案開發平台的軟體工程師，期盼有更多對自由軟體開發有興趣的夥伴踴躍加入我們的團隊，簡單說明如下：

【公司名稱】中央研究院、資訊創新研究中心、自由軟體鑄造場 (Open Source Software Foundry, OSSF)
【工作職務】網站程式開發工程師
【需求人數】1 名、履歷隨到即審。
【工作內容】設計與維護 OpenFoundry 專案開發平台
【工作地點】臺北市南港區研究院路 2 段 128 號 中央研究院 資訊科學研究所新館 402 室
【應徵資格】
◎ 專科以上：資訊工程，資訊管理，資訊科學等相關科系畢業生。
◎ 非資訊本科系畢業生，但具網站架設與程式撰寫方面的熟嫻技能並備作品可供參照者。

【必備條件】
◎ 伺服器管理經驗（UNIX-like OS，熟 FreeBSD 者尤佳）。
◎ Web-Based 相關的開發經驗
◎ 負責任的工作態度、細心認真、團體合作，正向態度的學習精神。

【加分條件】
◎ 熟悉關聯式資料庫設計與操作（熟 MySQL 者尤佳）
◎ 有業界多人共工專案的程式開發經歷，或在校內曾有相關經驗或作品者。
◎ 符合工作必備條件並領有直轄市、縣（市）主管機關核發證明之身心障礙者。

【工作待遇】依國科會標準敘薪，有工作經驗者另議。
【工作時間】日班　AM 9:00~PM 6:00
【應徵方式】
◎ 請檢附履歷、基本資料（學經歷、可安排之工作時間、聯絡方式等），寄予林誠夏，email: lucien AT citi.sinica.edu.tw
◎ 標題請註明：「應徵自由軟體鑄造場網站程式開發工程師-中文姓名」，履歷隨到即審，將於收到信後一週內擇優通知面試，不適任者恕不退件及函覆。
◎ 檔案請用 ODT 或 PDF 格式寄送。

[自由專欄] 維基經驗教給我們的事

Rex／文 2011-06-28

撰寫一個自由開放的百科全書，貢獻自己的微薄力量來成就一部海納百川的經典。說起維基百科的目標，總是冠冕堂皇地令人折服。但是在這宏大的理想口號之下，編輯維基百科的工作往往也受到一些誤解與質疑。

正如同開源軟體概念之初，總要面對封閉軟體將「智慧財產」與「改善軟體動力」綁定，強烈質疑一份原始碼全然公開的軟體，無法從中獲取收益而繼續開發工作。以 CC-by-sa 為授權方式的維基百科，同樣也面對許多人「編輯百科到底有什麼用？」的質疑，甚至更有些人直接推想參與維基百科的編者，可以從編寫過程中獲得稿費，不敢相信有人願意花時間、花精力貢獻知識而分毫不取。

我們實在也沒有必要唱高調，將功利的思想視為對開放的維基精神破壞。在開源軟體供應商已經從「販售服務」而非「販售軟體」中建立獲利的模式後，反而吸引了更多公司或個人投入開源的陣營；因此我們也不妨想一想如何在維基百科經驗中找出有利可圖之處，比起高唱熱血與分享，更能夠爭取到大眾的參與。
 

用戶貢獻 最誠實的履歷

首先要釐清的是，參與維基百科編輯帶來的核心價值不是「知識」，而是「求知的能力」。由於維基百科要求的不只是將腦中的知識貢獻出來，而是要找到可靠的文獻，將之消化，重新整理、組織、統合，才能夠完成一個受到其他編輯認可的作品。目前台灣許多活躍的編輯，還只是國、高中生，但是他們為了編輯條目，甚至會去主動尋找碩博士論文閱讀、改寫，能力遠勝許多只能從搜尋引擎上找到一般的網頁資料，複製貼上後就當成報告交差的大學生。翻閱一個編者的編輯紀錄，其實是比在校成績更不會說謊的能力保證。

其次，不同於撰寫個人部落格，維基百科由於開放、人人可以編輯，在編寫過程中會遭遇種種的衝突，需要具有溝通的能力、妥協的性格。這些也通通收錄在編者的「用戶貢獻」紀錄中，這些貢獻都是無法修改的紀錄，當然也是強而有力的證據。


▲ 圖1 作者 Reke 在中文維基百科的用戶貢獻
 

專題頁面 臥虎藏龍的人才庫

我們可以想像在社會普遍認識「維基履歷」的重要性後，編寫維基就不再只是一份熱血的義務工作。這份履歷在升學甄試、就業面試兩部分，都會成為讓一個好維基編者脫穎而出的有利資料。

事實上，對於一個企業來說，維基百科的價值除了可以做為求職者能力的準確參考之外，其實也是一個成本極低的人才庫。為了聯繫同好，便於協調條目的寫作，維基百科社群內部成立了不少協作組織，例如專題頁面、條目質量提升協作計劃的各項主題子計劃頁面。這些頁面不但可以紀錄成員在某個專業領域的貢獻，方便找出同時擁有熱情與專業知識的好工作伙伴。如果公司內部幹部平日業餘時就熱心參與社群的活動，建立合作的情誼，那麼在說服人才加入團隊時，更有事半功倍的效果。


▲ 圖2 中文維基百科上的台灣主題頁


當然，就像自由軟體的商機需要先有部分勇於開創的公司團隊，率先施行並獲得成功之後才可能得到大眾的認可，然而維基履歷的價值，也必須在維基社群發展較為活躍，有足夠組織力量向社會進行宣導，這樣的願景也才能夠成真。
 

作者簡介

Reke，台灣維基社群成員，PTT 電影板板主，主業為文字工作者。著迷於電影，耽溺於文字；在現實裡怯弱地柔從，在評論裡驕傲地反抗。電影部落格：http://rekegiga.blogspot.com/

報主的話

[源碼快報] 嵌入式裝置事涉侵權 – GPL 再次成為全球焦點

葛冬梅、林誠夏／編譯 2011-06-28

AVM (AVM Computersystem Vertrieb GmbH, AVM) 與 Cybits (Cybits AG) 這兩家德國公司，上週二 (6/21) 在柏林地方法院進行了一場 GPL 相關訴訟案的言詞辯論，AVM 控告 Cybits 修改其路由器產品的韌體，聲稱其著作權與商標權因此受到侵害，並主張 Cybits 的行為也同時違反了競爭法。由於涉及訴訟的產品利用到 GPL 授權的 Linux Kernel 與相關元件，因此預計本案對於未來 GPL 軟體的應用方式將會有重大的影響。知名的自由軟體開發者與 gpl-violations.org 組織創立者 Harald Welte，更以利害關係人的角色進行訴訟參加，實際參與並輔助 Cybits 進行法院審理與辯論程序。

原告 AVM 是一間 DSL 路由器的大型製造廠商，其所生產的路由器韌體中有利用到 Linux Kernel，涉案的主要產品為 FritzBox 路由器。Linux Kernel 是採用 GPL-2.0 授權的自由軟體，根據 GPL-2.0 的規定，使用者有散布與修改 Linux Kernel 的權利，而修改出來的衍生軟體也必須要繼續採用 GPL-2.0 來授權。被告 Cybits 是一家販售網路資訊過濾軟體的公司，主要產品為一款名為「Surf-Sitter DSL 」的兒童線上安全防護軟體，Surf-Sitter 會將 FritzBox 的韌體程式下載到使用者的電腦中，加以修改後，再安裝載回原來的 FritzBox 路由器當中。

早在 2010 年 1 月間，AVM 就以 Cybits 侵害其著作權，並且違反競爭法為理由，向德國柏林地方法院提出假處分的聲請，希望法院裁定禁止 Cybits 修改與安裝修改過的路由器韌體，雖然柏林地方法院裁定通過假處分聲請，但是 Cybits 對此裁定提出抗告，抗告法院嗣後駁回了原審的假處分裁定，AVM 因此聲請改行完整的法院訴訟審理程序，向 Cybits 提出相關的侵權訴訟，並且在上週二 (6/21) 進行了第一次的言詞辯論。Welte 與歐洲自由軟體基金會 (Free Software Foundation Europe, FSFE) 在本案仍處於假處分階段時，便積極協助 Cybits 處理本案，Welte 並以訴訟參加者的身份參與司法程序，以站在協助被告的立場來發表意見。

Welte 表示樂見商業公司利用他與數千萬開發者所共同開發出來的軟體，但是希望當他們在散布軟體的同時，可以將所接受到的權利也給予其他人享有。針對 AVM 對 Cybits 所採取的一連串法律措施，Welte 於言詞辯論前一天，在部落格發文譴責 AVM，他認為 AVM 嘗試透過法律途徑，防止 GPL 軟體使用者行使 GPL 所賦予的修改與執行修改版本的權利，是逾權的行為，因為這妨礙到自由軟體所給予使用者的基本自由。他表示：「通常我不太在意公司之間的訴訟，但是 Cybits 與 AVM 的案子不一樣，這個案子是關乎重要而基本的原則：一個利用 Linux 與其他 GPL 軟體的裝置製造商，並沒有權利透過法律手段，來防止程式的後續使用者行使 GPL 所賦予的重要權利！」因此 Welte 期望透過自己的介入，來影響法官對於訴訟案最後的判決。

AVM 聲請假處分所持的主要理由是，路由器的韌體是一個完整的軟體，是 AVM 透過創造的過程，將許多不同的部份結合在一起而成，屬於德國法上的編輯著作，因此 AVM 擁有路由器韌體的著作權，他人不得修改。不過 Welte 表示，路由器韌體既然有利用到 GPL 授權的軟體，依照 GPL 的規定，整個韌體就會受到 GPL 的授權拘束，使用者因此取得依 GPL 修改韌體的權利，又或者至少針對原本就採用 GPL 授權的部份，使用者必然是擁有修改權的。審理抗告的上級法院接受 Welte 的前述意見，因此駁回原審法院的假處分裁定。

在上週二的言詞辯論庭上，雙方繼續針對著作權、商標權與競爭法等相關部份進行辯論。AVM 一開始表示 Surf-Sitter 所修改的程式碼均為 AVM 自行撰寫的部份，針對使用者可以修改 GPL 授權程式碼這一點，並未多加爭執，因此辯論的重心轉移到侵害商標權與違反競爭法這兩個部份。AVM 表示，Surf-Sitter 修改韌體後載回路由器的行為，使用者並不知情，因此他人將會以為修改後路由器所產生的問題，也必須由 AVM 來負責，這對於 AVM 的利益造成了損害，也因而侵害了 AVM 的商標權。Cybits 與 Welte 則反駁，Cybits 自始並未使用 AVM 的商標進行商業宣傳，因此並未侵害 AVM 的商標權，此外，Cybits 依據 GPL 既然有權可以修改路由器韌體，並將修改後的韌體再次安裝、載入回原路由器中，因此 Cybits 的行為自然也沒有違反競爭法相關規定。Welte 的委託律師 Till Jaeger 則強調，路由器如同一台小型電腦，其上可以安裝與執行許多不同的服務功能與程式，假如商標法可以如同 AVM 所主張，用來防止他人安裝額外程式的話，那麼這對於整個 IT 產業將會是一場災難，因為這樣的觀點一經擴張解釋，現行市面上多數的品牌電腦皆將其商標標誌內嵌商品出貨，未來使用者將不能自行在其桌上或手持電腦上安裝任何其他的軟體。

整場言詞辯論的過程下來，法院認同 Jaeger 所提路由器如同電腦的論點，也認同路由器韌體可以作為一個整體軟體來看待，整個韌體因此都受到 GPL 所拘束，所以法院對於 AVM 所提出商標權相關的主張，是抱持懷疑的態度。不過法院並未當庭判決，訴訟的各方當事人還可以在一定期間內提出答辯狀，因此目前法院所表達出來的態度尚未是本案最終的判決結果。

言詞辯論之後 AVM 的一位發言人對媒體表示，AVM 一直遵守 GPL 的規定，提起這件訴訟案並非是要將 GPL 使用者權利的議題帶入到訴訟當中，但是 Surf-Sitter 修改其產品後，影響到產品的功能與介面呈現，FritzBox 的使用者有權使用功能運作正常的產品，因此 AVM 無法忍受此種修改裝置的行為。

歐洲自由軟體基金會與 Welte 所成立的 gpl-violations.org 組織在言詞辯論之後，分別在其網站上發佈新聞稿。歐洲自由軟體基金會的德國地區協調者 Matthias Kirschner 表示：「使用者有權自行決定，想要讓什麼樣的軟體在自己的電腦上跑。假如 AVM 或者任何其他公司不想要遵循 GPL 的遊戲規則，就不應該利用 GPL 授權的軟體。」gpl-violations.org 則特別強調，若是 AVM 勝訴，可能會讓資訊裝置製造商有權禁止使用者，在所購買的裝置上另外安裝軟體，使用者將因此被限制必須向特定製造商購買相關產品，此外，這也將會破壞目前在全球已經成功運行三十多年的自由軟體合作開發模式。

相關網址：

1. 歐洲自由軟體基金會對於本案內容的整理頁面
http://fsfe.org/projects/ftf/avm-gpl-violation.en.html
2. Harald Welte 於 6 月 20 日發表在其部落格上的文章
http://laforge.gnumonks.org/weblog/2011/06/20/#20110620-avm_cybits_gpl_violation
3. 新聞：Battle lines drawn in dispute between AVM, Cybits and FSFE
http://www.h-online.com/open/features/Battle-lines-drawn-in-dispute-between-AVM-Cybits-and-FSFE-1265227.html
4. gpl-violations.org 於 6 月 21 日的新聞稿
http://gpl-violations.org/news/20110620-avm-cybits.html
5. 歐洲自由軟體基金會於 6 月 21 日新聞稿
http://fsfe.org/news/2011/news-20110622-01.en.html

[源碼專案] Wine – 在 Linux 中使用 Windows 程式

Rex／文 2011-06-27

簡介

自從 Wine 1.0 在 2008 年六月釋出之後，便開始以兩、三周為週期，開始固定的釋出新版。Wine 是針對 POSIX 相容的作業系統所設計，目前 Wine 已經被移植到許多平臺上，除了 Linux 外，也可以在 Solaris，FreeBSD，x86 版本的 Mac OS 上使用。經過長期的開發與社群支援，目前在 Appdb 中已有超過一萬六千個軟體測試報告，其中有將近 3000 筆是屬於高度可用 (Platinum List) 的軟體。

在 Appdb 中仍有大量的軟體存在執行的問題，造成使用上的困擾，甚至無法使用。這與 Wine 的設計有關，Wine 跟 Dosbox，ZSNES 不同，既不是 模擬器，也不是 虛擬機器。它是以軟體方式模擬出 Windows 作業系統所需的軟體架構 (Software Stack)，理論上只新增一層 software layer 會比虛擬化成本低廉。

雖然 Wine 計劃經過十幾年發展，但是市面上目前為止沒有任何書籍介紹 Wine 及其程式架構，開發者只能參考少數幾份線上文件與 Wiki 網站上資料來理解 Wine 的程式架構。本文簡單地介紹 Wine 的相關設計。

軟體架構與初始化簡介

根據 Wine Developer's Guide，軟體架構如下：

▲ 圖1

要在 UNIX 中模擬一個 Windows 作業系統，有許多差異需要克服，且 Wine 為了開源授權的合法性，並不對 Windows 本身進行反組譯，而是用 黑箱測試法所開發出來，並參照開發文件逐步實做所有的 Win32 APIs。問題在與 Win32 API 文件並沒有完全開放，不同版本作業系統間，也有些微行為上的差異。然而 Windows® 有著為數不少缺乏文件的 APIs，甚至錯誤的 API 反應等等，Wine 都需要一一的實踐。加上仍有一些未開放的 低階 API，以及一些缺乏文件的協定或設計，Wine 計劃可以說是以血淚走過來的開發工作。

以 Wine 模擬 Windows 最重要的功能之一就是 Wine server，它基本上是提供作業系統核心模擬的功能，負責  Inter-Process Communication (IPC)，synchronization 與 process/thread management 等等工作。Wine server 是一個獨立的程序，每次啟動任何 Windows 程式前，它會優先被叫起。若出現了什麼問題，也要確保砍掉 (kill) 它後，才能乾淨的重新執行。

而在 Wine preloader 載入 . COM /  NE /  DLL /  PE 前，由於每個程序都將使用自己的 記憶體空間，Wine 要先依照不同的執行檔格式需求建立 Memory layout。為了能夠在 Linux 中製造出跟 Win32 一樣的記憶體位置，除了試圖將相關的 DLLs 載到正確的記憶體位置，Wine 也要避免 dynamic linker 預先把 Wine 所需的函式庫配置 (mapping) 到錯誤的位址，於是修改預設的 ELF 初始化程序，以 syscall 將相關的函式庫配置到正確的位置。

另外在 Windows 中，每個 process 或 thread 有一塊資料結構稱做 Environment Block (PEB–Process Environment block or TEB – Thread Environment Block)，這些資料中包含了  TLS slots，message queue，error code (SEH, Structured Exception Handling) 等等，這塊資料結構提供了 Windowing，Threading 以及錯誤處理等所需資訊。在建立 PEB/TEB 後，才初始化  process heap，載入執行檔，依照執行檔指示建立  stack，最後才將控制權交給執行檔的  EntryPoint。

上述工作均由 NTDLL/KERNEL32 處置，NTDLL/KERNEL32 也會負責傳遞執行序資訊給 Wine Server。至於啟動後的  Graphics Device Interface 與 X11 的圖形界面轉換由  GDI32 處理。 USER32 則實做 Windowing and Messaging subsystem，像是一些狀態列顯示等功能，都已經實做完成。

另外一個值得一提的是 錯誤處理的機制，在 Windows 上  exception handling 的方式比 Linux 中複雜許多。以  STATUS_ACCESS_VIOLATION / Segmentation fault 為例子，在 Linux 中只是吐一個  SIGSEGV 錯誤，在 Windows 中則會吐出一個  Exception，還會帶上錯誤位址 (faulting address) 等資訊，也可在 SEH 中指定 handler function 來處理錯誤事件。在 Linux 中，並沒有所謂的 system exception interface，Wine 為了模擬出 Windows 的 錯誤處理機制，將 exception 轉為 signal 來模擬。

除了上述幾個主要的核心程式外，Wine 也實做了許多軟體原件，像是 Cryptography、DirectShow Framework、Direct3D shader → GL mapper、Network protocol stacks、DirectSound (ALSA, OSS)、 DirectInput、 DirectShow、 DirectDraw、 Direct3D 等等。甚至連 MSHTML / IE 都已經以 Gecko Engine 實做。

目前 Wine 在編譯時，已經支援 64 bits 也支援 WoW64 來跑 32 bits 程式。
 

開發模式

Wine 是用 Git 管理，任何人都可以隨意 commit patches，test cases 到 patches mailing list 上，經過公開的 code review 後就會在下一次 release 中被合併。如果有任何技術上的疑問，則會被提到開發論壇進行討論，有歧異或暫時無法解決的問題，會被彙整到問題追蹤系統中，是個相當透明開放且平等的開發模式。

由於 Wine 是完全重製 Win32 APIs，且是黑箱測試開發模式，難免會出現修東壞西的悲慘現象。為了避免舊問題在新版中重現，Wine 設計了一套測試方法，來作 Regression Testing，藉此確保軟體品質。不過這個方法只能測試功能性的問題，還是避免不了一些圖形界面的變異。

Wine 計劃授權原本是採用 MIT，但在市場高度期待，出現了數家公司為不同的平臺提供服務，社群為了避免多家營利公司商業競爭造成開發資源分散，2002 年三月後已經改成 LGPL。 也由於授權開放，Wine 的開發成果，如：D3D 也被整合到 VirtualBox 中。另外像是想重新實做開源Windows® XP/2003 的 ReactOS 計劃，其軟體層也使用 Wine Libraries。一般開發者也可以用 Winelib 作為跨平臺的函式庫，在 Linux 上將程式移植到 Win32 平臺上（類似 mingw）。

目前在 Linux 上，Wine 對於音效支援，只有 OSS 與 ALSA。社群已有 PulseAudio，但由於開發團隊策略上的考量，希望朝支援 OpenAL 的方向走，因此尚未被整合到官方版本。至於在 MacOS 上，其圖形界面驅動程式還是 winex11.drv，需要 X Server 才能使用，OS X 上的 Quartz 在 2010 年時曾經有一部分實做，但已停止開發，功能也暫時無法使用。

使用現況

目前 Wine 計劃處在一個尷尬的狀態。Wine 已經完成很大部分的 Win32 Libraries，但仍有尚未實做的部分，為了能夠順利使用，使用者仍必須使用 Microsoft  函式庫（以下稱為 native）。又因為已高度實做 Wine 的函式庫（以下稱為 build-in）往往有不相容 native 函式庫的問題，因此對於使用者在現階段而言，並不容易只使用一套 Wine 設定，來套用所有的 Win32 應用程式。

結局就是造成使用 Wine 執行 Win32 程式時，常需要搭配不同的函式庫。例如這一版本需要 native 的 yyy.dll 配合 build-in 的 zzz.dll，另外一套軟體卻可以只用 build-in dll 執行。

如果軟體出現相容性問題，不再像初期一樣，只要靠換 Win32 Libraries 就可以排除，因為每個原生函式庫有高度相依性。由於安裝軟體時，常常需要用到一些 Microsoft 的程式碼，或者偶爾也許要微調一下 Windows Registry Keys 才能順利安裝。因此常需要透過特定道程序才能成功安裝，因此網路上有許多第三方工具，最常用也最知名的就是 Winetricks。

雖然 Wine 已經開始有些像是 Picasa，TeamViewer 等等的商用軟體應用，以 Wine 直接提供原生 Win32 程式給 Linux 平臺。但他們的做法，都是隨贈一套已調整完成的 Wine 系統。

由於 Wine 執行環境可以安裝在不同的 sandbox，因此系統中可以有多套不同的 Wine 同時執行。這種技巧叫做 bottle，使用者可以透過不同的環境變數，來設定 Wine 所要使用的設定檔路徑，載入 Win32 程式時，也會啟動不同的 wine server，不同的 bottle 會是獨立的執行環境，可作不同設定或安裝不同版本的函式庫。

使用者可以透過環境變數或第三方工具，來測試並配置各種不同的軟體，在 Linux 上可以使用今年剛發表的 wibom。在 MacOS 平臺上，由於編譯的困難性，可以使用 Wineskin 之類的工具來協助安裝管理 Win32 系統。此外，像是 CrossOver，Bordeaux 等公司也提供商業版的友善界面與預先調整好的安裝工具等服務。

在 Appdb 上已經有眾多程式資料，何不試試能否在 Linux 執行看看你最喜歡的 Windows 程式呢?
 

作者簡介

蔡志展 (Rex Tsai) 或網名 chihchun，現為自由工作者，從事開源軟體顧問或開發服務。倡議並推廣自由軟體與開放源碼，早期 KaLUG 成員，現常出席 Tossug、 HackingThursday 聚會，亦是開源人年會 (COSCUP) 籌備志工。長期 Debian、OpenWrt 使用者。關注議題甚廣，進一步資訊請參考 http://people.debian.org.tw/~chihchun/。