[法律專欄] 善用自由軟體資訊清單有效降低法律糾紛的風險

葛冬梅／文 2011-07-22

在協助處理各式各樣自由軟體授權問題的過程中，常常發現有許多廠商是在接到侵權警告信之後，才開始著手整理產品中所利用到的自由軟體元件，以及清查這些元件是採用哪一份授權條款來授權，這種事後的清整一來是非常耗時費工的，再者，這中間若有損害賠償的費用產生，廠商還可能因此必須負擔額外的金錢支出。其實這些額外的時間、人力與金錢支出，都可透過一些事前的措施來加以預防，並降低被認定為惡意侵權行為的風險，自由軟體資訊清單就是一個簡單而有效的方法。
【清單的內容】

顧名思義，自由軟體資訊清單記載了一個軟體專案中所利用到的自由軟體元件與授權相關資訊，在有需要的時候可以透過這份清單，讓他人快速而清楚地了解軟體專案所採用的自由軟體元件與授權資訊，有效運用的話，甚至可以降低未來法律糾紛發生的風險。清單的主要內容包括：自由軟體元件名稱與版本號、元件下載網址、授權條款名稱與版本號、商業應用相關資訊等。

1、自由軟體元件名稱與版本號

元件名稱必須正確而完整的記錄下來，若是元件有慣用縮寫的話，清單中除了縮寫之外，也必須將元件全名完整登載，以避免可能產生的混淆。而由於自由軟體在改版的同時可能會更改授權條款，因此即使是同一個元件，不同版本間的授權條款也可能不同，因此軟體元件的版本號也必須一併記錄。

2、元件下載網址

這部份的資訊可以只記錄一個直接下載元件的網址，也可以記錄下載連結所在的頁面網址，重要的是，其他人可以循著這個網址，再次下載到軟體專案中所利用到的這個自由軟體元件。

3、授權條款名稱與版本號

也就是記載元件採用到哪一份自由軟體授權條款，可以記錄授權條款全名，不過由於自由軟體授權條款的全名大多很長，再加上許多常見條款都有統一的縮寫方式，因此可以記錄條款的縮寫即可，而若是不清楚授權條款縮寫名稱的話，建議可以參考 SPDX 標準（註一）的規格書，規格書中訂有簡單而清楚的授權條款名稱縮寫表。此外，自由軟體授權條款承襲了程式開發的版本控制觀念，因此條款內容也會因為修改而產生新的條款版本，不同版本號的授權條款，內容差異可能相當大，所以授權條款的版本號也必須詳實的加以記錄。

4 、商業應用相關資訊

若是所開發出來的軟體未來可能被商業化運用，例如成為嵌入式裝置中的韌體加以販賣、技術移轉給商業公司利用等等，在整理這個清單的同時，就可以將一些與商業運用相關、重要的額外資訊一併記錄下來。例如：某某利用到的自由軟體元件同時亦有商業授權版本可以購買；某某元件的商標已被登記註冊，必須要另外支付商標授權費用才可商業散布等等相關資訊。

除了以上的主要內容之外，這份清單還可以包括其他與授權相關的重要內容，例如：元件所採用的授權條款與一般常見條款的不同之處；軟體專案自行開發的部份，是採用哪些另行標註的授權內容；註記不提供原始碼的私有軟體、第三方軟體，其與自由軟體元件之間的互動方式。這些額外的登載資訊，開發團隊可以視軟體專案的性質與個案狀況，來自行決定要如何微調清單的內容，同時，在一併登載非自由軟體元件的授權資訊後，這份清單也因此可以改為「XX專案軟體元件資訊清單」等符合實際內容的名稱。

然而，這份清單的內容建議是隨著軟體開發的過程來建立，也就是一邊開發、一邊記錄所利用到的自由軟體元件與授權資訊，尤其現在許多軟體專案的結構龐大，開發時程長達數年，若是沒有隨著開發過程適時地建立資訊清單，則事後可能需要花費更多的時間與人力來蒐集、整理這些過往的資訊。

【清單的運用】

這樣一份自由軟體資訊清單可以作為善盡法律上告知義務的證明文件，同時預防未來所可能引發的法律糾紛與損失，以下將舉個簡化的例子來說明。廠商甲委託廠商乙開發軟體專案 A，乙在開發 A 的時候，結合許多自由軟體元件，之後甲在市場上銷售 A，但是卻接到自由軟體元件 C 的著作權人丙的侵權警告信，甲轉而要求乙來承擔相關的責任與損失，由於的確是乙將 C 元件結合到 A 裡面，但是卻沒有告知甲相關的授權資訊與必須遵守的義務，因而導致甲遭遇到侵權糾紛，此時乙便極有可能因為其與甲之間的商業契約，而被要求一概承擔甲因侵權糾紛而後續肇生的一切賠償責任；然而，若乙在開發過程中，有仔細地整理其所負責開發的相關自由軟體資訊清單，並在清單中明列 C 元件的授權狀態與使用規則，且在交付 A 專案的同時，也將清單交給甲，透過這種清單編列與移交的方式，乙已經善盡告知義務，未來若仍然發生侵害 C 智慧財產權的法律糾紛，那麼相關的損失就必須由甲自己來承擔。由這個例子可以知道，這份清單可以作為善盡告知義務的證明，這樣甲乙雙方的責任範圍便可因此被切割的很清楚：若是有在清單上的元件未來發生問題，就由甲來負擔責任，反之，則是由乙來負擔責任。

除了應用在廠商委託、承包軟體的狀況外，一個利用到自由軟體元件的政府補助計畫，若是準備將計畫成果技術移轉給廠商，進行商業化運用的話，在交付計畫成果的同時，也可以給予廠商一份自由軟體資訊清單，以善盡告知義務，未來若發生自由軟體元件侵權的話，一旦權利受到侵害的自由軟體元件是在清單之列，那麼這個侵權責任就必須由接受技轉的廠商來自行來承擔（註二）。

當然，以上為簡化後的範例，實際業界的責任分擔關係往往更為複雜，而無法單純地透過這樣一份清單就將所有的責任釐清，但是在一般的原則下，這份清單確實是一個可以有效降低法律糾紛的實用方法。此外，在遇到使用者要求提供 GPL 類原始碼的時候，開發團隊可以透過清單快速了解，要提供的是哪些元件的原始碼，而適時整理清單的過程，會讓開發團隊利用自由軟體元件的行為變得較有意識，對於自由軟體與相關授權的知識也必然會有所增長，例如：開發團隊可以透過編列清單的工作，進一步了解哪些條款互相衝突，哪些條款授權的元件不可以直接結合利用，因此清單的建立也將可以間接降低開發團隊侵權利用自由軟體的機率。

【隨時記錄清單帶來長遠的良性利益】

記錄與整理自由軟體資訊清單的工作，同時也會耗用開發團隊額外的工時與精神，所以有些開發者或廠商可能覺得這是個擾人的方法，不過這樣的改變卻可以在利用自由軟體進行開發時，同步釐清與合作伙伴之間的責任分擔，同時還可以降低開發團隊因過失而侵權利用自由軟體元件的機率，因此長遠來看，這其實是一個利大於弊的方法。自由軟體的授權模式不同於以往傳統的軟體，在利用到這種新興軟體來進行商業營利的同時，當然也必須認知並適用到相對應的調整與應用模式，自由軟體資訊清單的整理是其中一個非常簡單的因應措施，透過這樣一個簡單的措施，可以導引出長遠的良性利益，因此除非已經有了非常完善的相關制度，筆者建議開發團隊或者是利用廠商都應該要循序建立清單的標準記錄流程，並且在移轉軟體的同時，附上這份清單，以有效降低不當利用自由軟體所可能衍生的相關法律風險。


註一：SPDX (Software Package Data Exchange) 是一套標示自由軟體授權資訊的標準，透過這套標準，使用者可以簡單快速地了解一個自由軟體元件的授權內容以及相關的資訊，如此將可減少自由軟體授權標示不清所引發的侵權利用問題。關於 SPDX 進一步的資訊請見：http://www.linuxfoundation.org/collaborate/workgroups/spdx/。

註二：若是政府補助計畫利用到自由軟體元件，並且有著後續商業應用的規劃，其他的相關注意事項可以參考：葛冬梅，運用自由軟體元件於政府補助計畫的後續商用建議，http://www.openfoundry.org/tw/legal-column-list/8174-2010-10-25-18-33-28。

[源碼新聞] 帶著台灣開源社群向前邁進的土虱－TOSSUG

李婉婷／採訪 2011-07-22

台北開放原始碼使用者社群 (Taipei Open Source Software User Group, TOSSUG) 是國內著名且歷史長遠的開源社群。TOSSUG 是個以台北為主要聚會場所的地方性社群，由於處於資訊密集且交通便捷的台北都會區，許多軟體開發的資訊從業人員聚集於此，社群參與聚會也相對活絡，在這樣的環境下，TOSSUG 社群聚會可以說是台灣相當重要且具有影響力的社群組織。許多國外的社群朋友來到台灣，往往會主動前來參與 TOSSUG 社群舉辦的聚會，以便與台灣的社群朋友進行面對面交流。所以、不論是想要一起研究最新的軟體開發技術，或是想要擴充人脈廣交益友，參與 TOSSUG 社群聚會絕對不會讓您失望。

TOSSUG 的相關活動，包括每週二晚上在 Mix Coffee & Tea 舉行聚會，這個聚會除了讓參與者輕鬆聊天、分享技術外，每隔兩到三個星期還會規劃一場專題演講，邀請國內各領域的開源人士分享其專精的主題。此外、TOSSUG 也經常透過國際友人的牽線，邀請國外開源專案的重要領導者與開發者，於其訪台時順道參與聚會，與台灣的社群朋友做更進一步的分享交流。這些演講安排提供國內社群朋友們相互交流知識的機會，也搭起了台灣開源社群與國際社群接觸的橋樑。

TOSSUG 聚會的設立目的，是要為國內開源技術的愛好者，提供了一個自由交流分享的環境，並能定期會面以成為散布創新能量的源頭。此社群最初是創始於四個研究生－Ping (pingoo)、Arne、Seventeen、Thhsieh 自行發起的小型聚會所演變而來。早在 2003 年時，由於原本所參與的社群聚會沒有繼續舉辦，這四個愛好 Linux 的參與者於是自行相約討論，持續透過彼此互助的方式，鑽研遇到的開發問題以及分享使用心得。後來陸續有人加入討論，於是這個小型聚會逐漸發展茁壯，最後才正式取名為 TOSSUG。

而到 2007 年時，當時國內開源界掀起一股社群成立法人組織的風潮，Ping 等人亦致力於其中，希望以 TOSSUG 之名申請一個法人組織，如此一來，未來在進行募款活動時便有了正式的名目，並且與其他組織合作時也較易處理相關的行政事宜。從這個時間點開始，TOSSUG 也開始透過志工自願參與的方式，採訪、編輯並出版了專職介紹台灣開放源碼各項資訊與動態的電子報－「土虱報報」。其後至 2008 年，TOSSUG 的 Mat 和 Thinker，與幾名專注在程式開發寫作方面的成員，因為想要將分享的內容聚焦在新技術的研究與開源專案的協同實作，又額外相約了星期四來進行聚會，最後催生了現在參與狀況與 TOSSUG 一樣活絡的 Hacking Thursday！

從原本的小型聚會到現在躍升為具有國際知名度的開源社群組織，TOSSUG 的成員並不僅是單單戮力於鑽研程式碼的寫作，對於開放源碼界相關的大小事，他們往往也不吝於投入目光持續關注，許多成員不僅花費自己的時間與精力，持續撰寫教化與普及開放源碼精神的專文，對於開源領域的各項事物，他們也呈現出高度的參與感與向心力。而儘管迄今 TOSSUG 並未如 2007 年所發動的雛議那般成立法人組織，但過去種種的努力也已經留下了紀錄，成為台灣開放源碼社群歷史與現階段發展中不可或缺的一部份。但 Ping 感嘆道：「最初的參與成員們陸續從學生身份畢業，接著去當兵、進入職場工作，現在仍具學生身份且能投注較多時間參與的成員已經佔少數。」因此他們也熱切希望能有更多年輕學子，能加入 TOSSUG 自由玩樂開放源碼的行列，並且期許新進成員能夠將自由軟體的分享精神與開源專案的合作風氣繼續傳承下去！

TOSSUG 官方部落格：
http://blog.tossug.org/

TOSSUG Google 網上論壇：
https://groups.google.com/forum/#!forum/tossug

Hacking Thursday 的介紹專文與相關資訊：
http://www.openfoundry.org/tw/foss-news/8355-hacking-thursday-

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

前言

在前二篇文章 CentOS 基礎設定（上）以及 CentOS 基礎設定（中），我們學習了 CentOS 主機的基礎設定。這些設定分別是：建立一般使用者帳號以便管理時使用；網路連線設定及連通測試；了解 SELinux 安全增強機制；將遠端允許 root 管理帳號登入的權限移除，以降低 CentOS 主機被密碼暴力測試工具攻擊的機會；了解  CentOS 主機的啟動流程，以及知悉何謂啟動模式等級 RunLevel；建立順手的操作環境 Shell 及檔案編輯器 VIM 環境設定；透過 sudo 建立管理者帳號的使用機制；將套件管理工具 YUM 下載來源由國外重新指向至台灣本地鏡像網站，以便縮短軟體套件及相依套件的下載時間。

本篇文章是 CentOS 基礎設定系列文章的最後一篇。首先要學習的是，當 CentOS 主機安裝設定完成後設定上線運作的方法，使系統定期自動寄送系統的相關記錄，並發至 CentOS 主機管理人員的郵件信箱內。這些相關紀錄包含：主機硬碟空間的使用率、郵件發送情況、網路服務運作狀況等資訊。因此企業中忙碌的 IT 管理人員，每天僅需檢查所收到的系統資訊郵件內容、檢查磁碟空間是否足夠、注意主機有無被攻擊的狀況等，並進行適當的調整即可，而不需要每天手動遠端登入至 CentOS 主機查看相關訊息，以節省寶貴的時間。

接下來學習的是，CentOS 遠端連線 SSH 的基本安全性保護設定，並在主機上線後，將系統時間定時自動與網際網路上的時間伺服器，或者與企業內部自行架設的時間伺服器校對時間。了解系統在進入啟動模式等級 RunLevel 後，會將哪些服務啟動，以及開啟哪些相對應的 Port。同時視系統需求關閉不必要的服務，以減少系統的負載並降低系統被攻擊的機會。最後，則是透過安裝 RPMforge，來增加 YUM 套件管理工具中可安裝的套件數量。

實作環境

* CentOS 5.5  32bit (Kernel 2.6.18-194.el5)
* sendmail-8.13.8-8.el5
* logwatch-7.3-8.el5
* xinetd-2.3.14-10.el5
* tcp_wrappers-7.6-40.7.el5
* pstree (PSmisc) 22.2
* yum-3.2.22-26.el5.centos
* rpmforge-release-0.5.2-2.el5

收集系統資訊後定期寄送給管理人員

當 CentOS 主機安裝、設定完畢並上線運作之後，我們希望主機能夠在固定時間（如每小時、每天、每週、每月）發送相關資訊至主機管理人員清單位址，讓主機管理人員能獲取系統上的服務運作狀態和硬體使用狀況相關資訊。主機的管理人員只要定期查看每台管理主機的資訊郵件內容，即可進行適當的處理，或轉交給相對應的人員接手處理。

CentOS 主機的預設排程為每小時的 01 分、每天凌晨 4 點 02 分、每週日凌晨 4 點 22 分，以及每月 1 號凌晨 4 點 22 分。此時，系統會執行預先撰寫好的自動維護 Shell Script 執行檔，進行系統相關的清理及備份工作，並使用預設的郵件轉送代理 (Mail Transfer Agnet, MTA) Sendmail 寄送資訊郵件。欲使用別的郵件轉送代理像是 Postfix、Qmail 等 ，屆時只要在設定檔內進行指定即可。若讀者有興趣了解系統定期執行的詳細內容，可切換至 /etc 目錄下的四個資料夾，分別是：每小時 (cron.hourly)、每天 (cron.daily)、每週 (cron.weekly)、每月 (cron.monthly)，每個資料夾內都有相關的自動維護 Shell Script ，查看後即可了解系統維護主機的相關內容。

▲ 圖1 查看主機系統排程資訊

在 CentOS 系統中，LogWatch 套件負責收集系統狀態及相關網路服務運作資訊（預設情況下會安裝至系統）。我們可以在每天定期發送的 cron.daily 資料夾中，發現 0logwatch 這隻 Script。也就是說，系統會在每天凌晨 4 點 02 分時，透過此 Script 將系統中系統、硬體、服務的資訊收集後，寄送給各個管理者。接下來便說明相關資訊的設定方法，如：由哪台主機寄出收集後的資訊、寄件對象、系統資訊收集分析的等級、收集主機服務運作的狀態設定等。

我們可以將相關設定值寫入至 LogWatch 設定檔 "/etc/logwatch/conf/logwatch.conf" 內，操作中相關設定值參數及說明如下：

* MailFrom：通常填入此台主機的主機名稱 (Hostname)，或是該主機所擔任的企業服務名稱（如 Web1）。
* MailTo：填入管理者們的郵件信箱 (Email)。若有多筆郵件位址，則使用逗點 (, ) 加上空格進行隔開即可。
* Detail：指定收集主機資訊後分析的等級，共有三種等級可供選擇。分別為低級（Low 或數字 0）、中級（Med 或數字 5）、高級（High 或數字 10）。
* Service：指定收集主機服務運作的項目，LogWatch 支援收集服務的項目為 /usr/share/logwatch/scripts/services 目錄下的服務名稱，您可以使用參數 All 來表示要收集該主機所有運作的服務。若不想分析某個服務，則可於服務名稱前加上減號 ( - )，則系統便會排除收集該項服務的運作狀態。

下列為筆者的 LogWatch 設定檔設定內容，若您需要更詳細的參數設定內容可參考 "/usr/share/logwatch/default.conf/logwatch.conf" 設定檔內容


▲ 圖2 LogWatch 設定檔內容

設定完畢之後，CentOS 主機便會自動於每天凌晨 4 點 02 分時，收集主機資訊後寄送至管理者郵件信箱內。如果您想要立即收到資訊郵件，可以手動執行 logwatch 指令，命令主機立刻收集資訊並寄送郵件，或配合參數 --print 直接顯示收集到的資訊，查看收集到的資訊而不寄送郵件（此資訊和資訊郵件的內容完全相同）。您還可以配合參數 --service ，僅顯示收集的服務名稱運作狀態。


▲ 圖3 logwatch 查看指令以及立即寄送資訊郵件操作

如果您已經設定完成，但並沒有定期收到資訊郵件的話，可以先用 mailq 指令，查看郵件是否被佇列 (Queue) 住。接著，檢查郵件記錄檔 /var/log/maillog 內容以及主機的 DNS 設定，分析並查找管理者沒有定期收到主機所收集資訊郵件的原因。此外，由於系統會在隔一段時間後才送出郵件，若您執行 logwatch 指令寄送郵件時，發現郵件在郵件佇列中而未立即寄出，可執行 sendmail 指令，配合參數 –q，使主機立刻寄出郵件佇列中所有郵件。


▲ 圖4 檢查郵件佇列及查看郵件記錄檔以及立刻寄送郵件出去


▲ 圖5 管理人員收到的每日系統資訊郵件內容

SSH 基礎安全防護設定

在 CentOS 主機中，我們可以利用許多機制來保護主機服務。IPTables 防火牆功能強大，是安全防護選項之一，但本文中並不打算講解有關 IPTables 防火牆設定（若要講解的話得再開一系列文章），而是要介紹另一個設定簡單，有一定保護程度的安全機制 TCP Wrappers 達到保護 SSH 遠端連線服務的效果。此服務與系統內的 xinetd 服務有很深的關聯，下圖便清楚表達了當網路封包進入 CentOS 主機時，Firewall、TCP Wrappers 及 xinetd 服務的封包走向關係圖。


▲ 圖6 圖片來源 CentOS 官方網站 Deployment_Guide - 42.5. TCP Wrappers and xinetd，採用 Open Publication License

預設情況下，TCP Wrappers 在安裝 CentOS 主機過程中便已安裝完成。而顧名思義，此安全防護機制僅能保護 TCP daemon，而無法保護 UDP daemon（仍有例外狀況）。相信您會接著問，那 TCP Wrappers 能夠保護主機上哪些服務項目呢？ 答案是，只要該服務中含有 libwrap 函式庫 (Library)，即可受到 TCP Wrappers 保護。經由下列操作，我們便可了解如何檢查該服務內是否含有 libwrap 函式庫。在圖 7 中，我們可以看到 SSH 服務 (sshd) 含有 libwrap 函式庫，而 Apache 服務 (httpd) 則沒有包含 libwrap 函式庫。所以雖然都是 TCP daemon ，但 TCP Wrappers 可以保護 SSH 服務，而無法保護 Apache 服務。


▲ 圖7 查詢 TCP Wrappers 是否可以保護該服務

接著要說明的是 TCP Wrappers 的保護規則。在安全防護設定上，TCP Wrappers 非常簡單易懂，不像防火牆設定那麼複雜。其安全防護規則採用 First Match 方式，意即先讀取到的規則直接套用執行後，便不需要理會後面的規則。

TCP Wrappers 的防護規則分為 "/etc/hosts.allow" 及 "/etc/hosts.deny" 二個設定檔。這二個設定檔中，首先讀取的設定檔為 hosts.allow，若此設定檔中有設定服務名稱，則允許封包通過，接著讀取 hosts.deny 則為禁止封包通過。筆者建議僅設定 "/etc/hosts.allow" 設定檔便可達到防護效果。

在修改 TCP Wrappers 保護規則設定檔 (/etc/hosts.allow) 以前，我們先了解設定檔的內容及相關參數的意義。設定檔內容可以分成三個小區段來看，分別是「服務名稱 (deamon)、來源 IP 位址或網域名稱 FQDN、連線回應為允許 (allow) 或拒絕 (deny)」。每個小區段之間使用冒號 (:) 作為分隔符號，在前面二個小區段中並支援相關進階參數，使保護規則運作更靈活。但是，若使用 KNOWN、UNKNOWN、PARANOID 參數時，請注意此三個參數是依靠 DNS 名稱解析服務，因此必須要注意主機上的 DNS 名稱解析是否運作正常，相關進階參數說明如下：

* ALL：表示 「全部 」，用於第一個小區段（服務名稱欄位）表示全部服務，用於第二個小區段（連線來源）表示全部的 IP 位址或網域名稱 FQDN。
* LOCAL：表示「本機」，也就是不含點 (.) 的主機名稱例如 localhost。
* KNOWN：表示「可解析主機」，也就是可以解析其 IP 位址及網域名稱 FQDN。
* UNKNOWN：表示「無法解析主機」，也就是無法解析其 IP 位址及網域名稱 FQDN。
* PARANOID：表示「正反解析必須一致」，也就是 DNS 正解（FQDN 解析 IP 位址）及 DNS 反解（IP 位址解析 FQDN）二者的解析記錄必須一致。
* EXCEPT：表示「排除」的意思，例如允許 192.168.1.0 這個網段的所有主機，但排除 192.168.1.99 這個 IP 位址。

在設定之前，還有三個小地方要提醒讀者注意。首先是來源 IP 網段的遮罩設定值，TCP Wrappers 支援的網路遮罩為 255.255.255.0 這種型式，而不是 /24 這種 CIDR 表示方法。若您設定 /24 這種網路遮罩，則該行防護設定規則將無法運作（但若是來源位址使用 IPv6 位址則支援此種表示方法）。第二點要注意的是，修改 TCP Wrappers 設定檔內容後，當您存檔離開的那一剎那，所設定的防護內容便立刻生效（不需要重新啟動或載入 xinetd 服務）。最後要注意的是，防護規則僅套用於「新進 Session」，也就是說，設定阻擋規則時主機上若已經存在有舊的連線 Session，並不會自動斷線離開，而是新進來的 Session 才會阻擋。

CentOS 在預設情況下並不會安裝 xinetd 套件，我們可以透過前一篇介紹的 yum 指令來安裝 xinetd 套件。此次我們以防護主機上的 SSH 服務為例，設定只有允許的 IP 網段可以使用 SSH 遠端登入此台 CentOS 主機（允許連線後接著才進行使用者帳號及密碼驗證），並且拒絕允許的 IP 網段中，其中一台主機的連線要求。最後，其餘的 IP 位址欲嘗試使用 SSH 遠端登入主機時，則拒絕其連線要求。由於已經拒絕連線要求封包，因此主機自然就不需要回應使用者帳號及密碼的驗證動作，此舉能夠有效減低 CentOS 主機被進行密碼暴力測試工具攻擊的機會，提升主機整體安全性。

下列操作步驟包含利用 yum 套件管理工具安裝 xinetd 套件，查看 xinetd 服務是否在 CentOS 主機啟動時自動啟動 xinetd 服務，確認無誤後啟動 xinetd 服務。接著設定 TCP Wrappers 設定檔 (/etc/hosts.allow)，其內容為允許 192.168.1.0 整個 C Class 網段主機 SSH 遠端連線至此台 CentOS 主機，除了 192.168.1.99 禁止連接。最後，其餘 IP 網段若發出 SSH 遠端連線要求時，則直接拒絕該連線封包。


▲ 圖8 安裝 xinetd 套件及設定 TCP Wrappers 安全防護規則

上述 TCP Wrappers 防護規則設定完成後，我們可以進行驗證，檢查剛才設定是否生效。我們由 192.168.1.99 主機對目前 CentOS 主機 (192.168.1.50) 發出 SSH 遠端連線要求，並得到 Connection closed 的連線拒絕回應。在 CentOS 主機上，我們查看 secure 記錄檔也可看到 192.168.1.99 主機嘗試 SSH 遠端連線此台主機，並遭到拒絕連線 (refused connect) 的回應。而 192.168.1.0 網段中的其它主機發出 SSH 連線要求時，則會出現驗證帳號密碼的動作。


▲ 圖9 驗證 TCP Wrappers 防護規則是否生效

經過上述實作驗證後，相信讀者已經了解如何用簡單的 TCP Wrappers 安全防護規則，來保護 CentOS 主機。若您認為 TCP Wrappers 只有這些功能的話，那您就大錯特錯了。TCP Wrappers 支援更進階的安全防護規則內容，例如嘗試連線記錄、結合 Shell 指令等功能。但是在這些進階的防護功能中， 嘗試連線記錄必須要搭配系統的日誌服務 (syslogd) 才得以運作，而結合 Shell 指令功能，除了必須對系統指令有一定程度了解之外，還必須了解如何搭配相關的參數，才得以發揮強大效果。建議有興趣更深入的讀者，可以參考 CentOS 官方文件 Deployment_Guide - 42.5. TCP Wrappers and xinetd 內有進階設定的詳細說明。

 

系統時間自動校對

網路時間協定 NTP (Network Time Protocol) 最初由德拉瓦州大學 (Delaware University) 的大衛米爾斯 (David L. Mills) 所設計，主要目的為透過網路封包交換 (UDP Protocol, Port 123)，將二端電腦的時鐘進行同步校對。若讀者想更詳細了解整個 NTP 協定的規範、實作、分析等詳細內容，請參考 RFC 1305 (NTP version 3)、RFC 5905 (NTP version 4)。

企業營運環境的伺服器為數眾多，倘若伺服器之間的時間不同步，可能會造成許多影響。例如伺服器之間的時間誤差超過 5 分鐘時，則將導致 Kerberos 的驗證失敗；或者，當企業購物平台的前端 AP 伺服器與後端資料庫伺服器時間不同步時，則使用者下單記錄可能在資料庫伺服器上顯示為未來時間，或是優惠活動時間明明已經結束，但使用者仍然可以下單購買，造成客服人員的困擾；再者，公司財務報表產生時，若伺服器之間的時間不同步，則會造成財務報表合併時在核對上出現困擾。以上舉例的種種問題，追究其原因，便是由於眾多伺服器之間時間不同步所造成。

在此次設定中，我們為 CentOS 主機安裝 OpenNTPD 客戶端，來進行系統運作時間校對。OpenNTPD 客戶端與一般的 NTP 客戶端時間校對方式有著明顯的不同，一般 NTP 客戶端的時間校對方式為「強迫性一次調整到位」，也就是不管現在系統時間，一律直接跟 NTP 伺服器校對後調整。偏向暴力性的一次到位調整時間的方式，在某些狀況下可能會對主機運作穩定性上產生問題。而此次安裝的 OpenNTPD 客戶端的時間校對方式為：當 OpenNTPD 客戶端與 NTP 時間伺服器有時間誤差時，OpenNTPD 客戶端會將主機每隔幾分鐘進行系統時間「微調」，慢慢調整，直到最後與時間伺服器上的標準時間達成一致。這樣溫和的時間調整方式，對於要求高穩定性的企業營運環境伺服器來說，相對而言是比較適合的。

在安裝 OpenNTPD 客戶端以前，請您先使用 rpm –qa 指令來確認 CentOS 主機是否已經安裝 gcc 及 make 套件（若系統沒有安裝，請使用 YUM 套件管理工具進行 yum –y install gcc make 安裝指令），以便在安裝 OpenNTPD 套件時能順利進行編譯 (Compile) 與安裝 (make)。在設定前，您可以故意先將 CentOS 主機系統時間調慢 5分鐘，待之後啟動 OpenNTPD 服務後，即可發現系統開始跟 NTP 時間伺服器慢慢進行時間校對。

在 CentOS 預設的 YUM 套件管理工具中，並未收錄 OpenNTPD 軟體套件，因此請自行從 OpenBSD 的鏡像站台下載、解壓縮、編譯，並安裝 OpenNTPD 套件。下列操作步驟為先利用 wget 指令下載 OpenNTPD 套件至 /tmp 資料夾下，並將 OpenNTPD 套件檔案解壓縮後執行 ./configure、make、make install 等指令，將 OpenNTPD 套件編譯並進行安裝。


▲ 圖10 OpenNTPD 套件下載、解壓縮、編譯、安裝

在上述最後執行套件安裝的動作 make install 時，我們可以看到，系統提示我們必須要為系統建立 _ntp 的使用者帳號及群組，以便屆時使用 _ntp 使用者帳號來啟動 OpenNTP 服務，而非使用 root 管理者帳號，以避免安全性問題。因此安裝完畢後，請使用 useradd 及 groupadd 指令，配合相關參數來新增 _ntp 使用者帳號及群組，接著設定 OpenNTPD 設定檔，指向至企業內部所架設的 NTP 伺服器或網際網路上的 NTP 伺服器 IP 位址。接下來如圖11 將 NTP 伺服器指向至國家時間與頻率標準實驗室，進行時間校對。最後，設定 OpenNTPD 記錄檔來記錄主機時間校時的狀況，並在完成後重新載入系統日誌服務 syslogd，讓其變更生效即可。


▲ 圖11 完成 OpenNTPD 客戶端相關設定，並建立記錄檔了解校時狀況

接著將 OpenNTPD 新增至 CentOS 內建的服務清單內，設定當 CentOS 重新開機時能夠自動啟動 OpenNTPD 服務，自動與國家時間與頻率標準實驗室 NTP 伺服器進行時間校對作業。完成設定後即可啟動 OpenNTPD 服務，並透過剛才建立的記錄檔來觀察目前主機與 NTP 伺服器進行時間校對的情況。


▲ 圖12 新增 OpenNTPD 為系統服務並查看主機校時情況

 

查看系統啟動服務及監聽 Port 號

了解系統啟動的服務以及該服務開啟的相應 Port ，也是主機安全防護的基本功。我們可以使用內建的 netstat 指令，配合 –tunpl 參數，顯示系統目前啟動服務及協定等相關資訊。使用到的 5 個參數意義為 t (TCP)、u (UDP)、n（IP 位址及 Port 號）、p（PID 名稱）、l (Listen) 服務，這些指令執行後顯示出來的相關欄位解釋如下：

* Proto：服務運作的協定，通常為 TCP 或 UDP Protocol
* Recv-Q：收到的封包 Bytes 數量
* Send-Q：傳送的封包 Bytes 數量
* Local Address：本地端的 IP 位址及 Port 號
* Foreign Address：遠端主機的 IP 位址及 Port 號
* State：連接狀態，此例中僅顯示 Listen 狀態，實際上還有已建立連線 (ESTABLISHED)、連線結束等待 Socket 關閉 (TIME_WAIT)、主動連線 SYN 封包 (SYN_SENT)、連線要求 SYN 封包 (SYN_RECV)等狀態。
* PID/Program name：該程序 (Process) 的名稱


▲ 圖13 查看主機目前啟動的服務及相對應的 Port 號

透過運用 netstat 指令了解 CentOS 主機執行哪些服務 (daemon)，與開啟哪些 Port 號之後，我們可以進一步透過了解執行序，在系統或服務出現問題後利於除錯。若只是要查詢系統有哪些執行序時，我們可以使用內建的 ps 指令，配合相關參數進行查詢。但若是想要了解執行序的樹狀結構（意即母程序及子程序的樹狀關系）時，內建的 ps 指令可能就略顯不足。此時可以配合 pstree 套件來輔助我們即時了解執行序樹狀結構，例如我們查詢剛才執行的校時程序 ntpd 的執行序樹狀結構，可以看到整個 ntpd 的母程序 PID 為 21815，並且使用 _ntp 使用者帳號負責帶起子程序 PID 21816。

▲ 圖14 查詢 OpenNTPD 服務的執行序樹狀關系

接著我們可以使用 chkconfig 指令，以了解 CentOS 主機在開機時進入不同的 RunLevel 時會啟動的服務。我們以主機所擔任的服務，來判斷是否有些不會用到的服務，例如 acpid (Advanced Configuration and Power Interface) 電源進階設定，這個服務是將 CentOS 安裝於筆記型電腦上才會發揮效用，所以我們就可以將該服務關閉。此舉除了可以增加系統效能（啟動每個服務都會佔用記憶體），還可以避免該服務被攻擊，增加系統安全性。

下列操作為 CentOS 主機預設啟動程序在 RunLevel 3 的狀況下，我們使用指令 chkconfig 指令配合相關參數，來了解系統在 RunLevel 3 時，開機會自動啟動哪些服務：


▲ 圖15 檢查主機於 RunLevel 3 啟動時會啟動哪些服務

當您決定哪些服務要開啟，而哪些服務要關閉後，就可以執行「關閉啟動主機時不啟動服務」或是「停止該服務」。下列操作中，我們以 acpid 服務為例進行設定，當主機由 RunLevel 3 啟動模式啟動時，不會自動啟動該服務，並在目前運作模式下馬上停止該服務的運作：


▲ 圖16 關閉 acpid 於 RunLevel 3 時自動啟動，並立即停止該服務

 

擴充 YUM 套件管理工具 RPM 數量

雖然在上一篇文章中，我們已經將 YUM 套件管理工具的鏡像站台，設定為台灣鏡像站台來加快套件下載速度。不過雖然目前官方的 YUM 套件管理工具中套件數量已經不少，但目前官方套件數量中僅包含必要套件，例如常常用來管理 MySQL 資料庫的 PhpMyAdmin 套件，就未包含在內建的 YUM 套件庫 (RPM Repository) 當中。

雖然我們可以自行下載 PhpMyAdmin 套件並手動安裝到系統上，但筆者個人的主機管理習慣，是盡量使用 YUM 套件管理工具來處理 RPM 套件的安裝、移除、升級。因此在這裡要介紹讀者一套名為 RPM forge 的套件，我們可以安裝它來擴充 YUM 套件管理工具中的套件數量。

RPMforge 支援許多 Linux 發行版本，例如 RHEL、Fedora Core、CentOS、Scientific、Aurora 等。將 RPMforge 安裝於系統之後，可擴充系統 YUM 套件管理工具中的套件數量，例如剛才提到的 PhpMyAdmin 套件。我們可以在安裝 RPMforge 之後，透過 yum 指令來進行安裝，而不需要自行上網尋找該套件。

下列操作中，我們可以看到當系統尚未安裝 RPMforge 以前，其 YUM 管理工具套件庫 (RPM Repository) 中搜尋不到 PhpMyAdmin 套件。當安裝 RPMforge 之後，便可順利透過 yum 指令來進行安裝。每次安裝時，請安裝最新發行穩定版本的 RPMforge-Release，並注意您使用的 CentOS 主機是 32 位元或 64 位元的作業系統版本（本次實作為使用 CentOS 5.5 32 位元版本）：


▲ 圖17 未安裝 RPMforge 以前搜尋不到 PhpMyAdmin 套件


▲ 圖18 安裝 RPMforge 後可順利搜尋到 PhpMyAdmin 套件

 

結語

雖然網路上 Linux 相關參考資源及教學非常多，但筆者發現許多 Linux 初學者可能對於 CentOS 主機的系統基礎設定不熟悉，或者未設置相關設定，導致在學習上發生瓶頸。例如沒有把 YUM 套件管理工具的預設鏡像站台由國外設回國內，因此認為 CentOS 主機套件安裝速度相當緩慢。追究其原因，只是因為未更改鏡像站台至國內，加上所處的網路環境頻寬不是很理想，導致下載套件及相依套件時速度緩慢，而造成使用者的誤會。又或者因為沒有把 SELinux 安全機制暫時關閉，所架設的網路服務因而違反了 SELinux 的安全機制，導致服務啟動時被阻擋住而無法啟動成功。

若因為不熟悉這些設定而放棄學習 CentOS，是非常可惜的一件事。筆者期望能夠透過這三篇 CentOS 基礎設定文章，讓讀者對於 CentOS 作業系統有初步的認識，並在配合相關基礎設定的實作之後，能夠協助讀者建立一個屬於自己，順手好用又安全的 CentOS 作業系統。

[源碼秘技] 用自由軟體 Plone 來架設網站(9)一多媒體結合

marr／文 2011-07-25

依照內容資料的脈絡，Plone 有幾種不同的顯示方法：套用 Archetypes 的內容型別，擁有獨立配套的管理方式；單獨的網頁，可以用 Browser View 來控制；常見的個別表單，可以用 PloneFormGen 來處理。不管是哪種方法，結合 AJAX、Flash 之類的工具，混搭式地呈現內容，已經是主流作法。之前介紹過的 Faceted Navigation 模組，內部使用大量 jQuery 函式庫，我們將延續介紹其他常見的應用方式，例如批次上傳檔案，內嵌方式顯示圖檔、影片、PDF，或是其他線上服務的內容。

另外，訊息中文化的方法，也是許多朋友關心的議題，本文將介紹常見的訊息翻譯步驟和技巧，說明如何利用 i18ndude 和 gettext 協助中文化。

允許 HTML 標籤

為了系統安全及外觀風格一致的因素，Plone 預設會過濾特定的 HTML 標籤，會被過濾的標籤清單，請由 Site Setup → HTML Filtering 檢視設定畫面，如圖1 所示。


▲ 圖1 會被過濾的 HTML 標籤清單 

舉例來說，編輯內容時，即使指定使用 embed 或 object 之類的 HTML 標籤，存檔之後仍然消失，原因就是被過濾掉了。該怎樣啟用這些 HTML 標籤呢?

最安全的方式，是使用模組，在檔案系統裡指定這些操作行為。如果你的網站僅開放帳號給特定人員，而且他們都能被信任，則可以考慮直接取消過濾清楚的限制。方法是勾選要取消的項目，點選 Remove selected items 按鈕，最後要再點選最下方的 Save 按鈕，才真正完成生效。

以嵌入 Flickr 照片為例，點選 Share 後，從 Grab the embed HTML 複製程式碼，如圖2 所示。


▲ 圖2 Flickr 內嵌程式碼範例

在 Plone 編輯介面，點選 HTML 按鈕，把複製的 HTML 程式碼，貼到 HTML 編輯器裡，如圖3 所示。

▲ 圖3 複製程式碼到 HTML 編輯器的範例

完成的畫面類似圖4 所示。


▲ 圖4 內嵌 Flickr 照片的範例畫面

同樣的道理，類似 iframe 之類的標籤，並不是 XHTML 的定義項目，想要使用它們的話，必須額外指定，方法是在 Custom tags 設定欄位，先點選 Add Custom tags 按鈕，再填入 iframe 設定值，記得再點選 Save 按鈕完成生效。如圖5 所示。


▲ 圖5 新增 iframe 成為允許的標籤

使用模組展示圖檔

支援圖檔展示的模組很多，collective.plonetruegallery 是佼佼者，以 Plone 4.1 環境為例，安裝方式只要在 eggs 參數設定值，加上 collective.plonetruegallery[all] 就行，如圖6 所示。最後面的 [all] 代表同時支援 Flickr 和 Picasa 服務。


▲ 圖6 在 develop.cfg 新增 PloneTrueGallery 模組

執行 bin/buildout -c develop.cfg 後，會安裝 flickrapi 和 gdata 相依模組，在 Site Setup 的 Add-ons 啟用模組後，就可以在目錄的 Display 下拉選單，看到 galleryview 選項，如圖7 所示。


▲ 圖7 點選 galleryview 可以啟用新的檢視功能

顯示圖檔的管理單位是目錄，啟用 galleryview 檢視功能後，會新增 Gallery Settings 頁籤，如圖8 所示。


▲ 圖8 Plone 目錄圖檔的顯示畫面

在設定主頁面可以看見支援 Plone、Flickr、Picasa 三種類型，還有許多選項和 AJAX 特效可以設定，如圖9 所示。


▲ 圖9 Gallery 設定主頁面

想要選用 Flickr 類型的話，先在 Main 頁籤的 Type 選擇 Flickr，再到 Type Settings 頁籤，填寫 Flickr 的帳號和 Set 名稱，如圖10 所示。


▲ 圖10 設定 Flickr 帳號和 Set 名稱

目錄輪播的圖片換成來自 Flickr 的圖檔，如圖11 所示。


▲ 圖11 輪播 Flickr 圖片的畫面

你還可以用 Gallery Portlet 來顯示圖片，設定範例如圖12 所示。


▲ 圖12 Gallery Portlet 設定畫面

使用模組展示影片

試用過 redturtle.video 模組，它提供影片展示的功能，並支援 Youtube 之類的外部服務。安裝方式是在 eggs 參數設定值，加上 redturtle.video 就行，執行 buildout 會再安裝 collective.flowplayer、hachoir-core、hachoir-metadata、hachoir-parser 等，成功啟用後的模組範例如圖13 所示。在 Plone 4.1 環境，可能會遇到 formlib 問題，修改 from Products.Five.formlib import formbase 成為 from five.formlib import formbase 就行。


▲ 圖13 RedTurtle Video 模組啟用畫面

啟用 RedTurtle Video 後，在內容項目的新增選單，可以看到 Video file 和 Video link 兩個型別，如圖14 所示。


▲ 圖14 Video file 和 link 新型別

以新增 Video file 為例，必填的欄位包括 Title 和 Video file 檔案位置，如圖15 所示。


▲ 圖15 Video file 編輯畫面

Video file 的顯示畫面，包括一個 FlowPlayer 播放區域，並顯示影片長度，如圖16 所示。


▲ 圖16 Video file 顯示畫面

接著，在目錄的 Display 下拉選單，可以看到 flowplayer 選項，點選之後，目錄裡的影片檔案會併列顯示，並直接在 FlowPlayer 播放，如圖17 所示。


▲ 圖17 啟用 flowplayer 顯示方式的目錄畫面

顧名思義，Video link 就是用來播放外部影片服務的型別，圖18 是搭配 Vimeo 的編輯畫面，想要使用 Youtube 服務的話，要再安裝 collective.rtvideo.youtube 模組。


▲ 圖18 Video link 編輯畫面

使用模組批次上傳

想要批次上傳多個檔案，可以借助 Plone Quick Upload 模組，在 eggs 參數設定值加進 collective.quickupload 執行 buildout 就搞定安裝。在 Site Setup 的 Add-on Configuration 會看到 Quick Upload 的設定選項，如圖19 所示。


▲ 圖19 Quick Upload 設定選項

Quick Upload 搭配 Portlet 來顯示批次上傳的操作介面，稱為 Quick Upload Portlet，設定畫面如圖20 所示。


▲ 圖20 Quick Upload Portlet 設定畫面

操作介面支援 JavaScript 和 Flash 兩種方式，預設是使用 JavaScript。選定檔案後，預設可以指定標題，如圖21 所示。


▲ 圖21 Quick Upload 操作介面

中文訊息的支援機制

Plone 內部使用 gettext 工具處理多國語文的支援，翻譯的內容先存在 .po 檔案裡，經過系統編譯成 .mo 檔案，就可以直接被 Plone 讀取。系統翻譯檔由 plone.app.locales 模組管理，正體中文的翻譯檔位於 locales/zh_TW/LC_MESSAGES 目錄裡。

想要設定訊息語系為正體中文，請到 Site Setup 的 Language 指定，要記得勾選 Show country-specific language variants，這樣才會出現 Chinese (Taiwan) 選項，如圖22 所示。


▲ 圖22 設定訊息語系為正體中文

以之前的 mysite.eventfolder 模組為例，在 mysite/eventfolder/__init__.py 檔案裡，看得到它載入 zope.i18nmessageid 的 MessageFactory，透過 message factory 可以把程式碼裡以「特殊符號」標記的訊息字串，萃取成為待翻譯的內容。如圖23 所示。


▲ 圖23 message factory 的宣告範例

所謂特殊符號標記的訊息字串，常見有兩種，一種是以「底線符號」來標記，如圖24 所示。


▲ 圖24 底線符號標記的訊息字串

另一種是以「i18n:」字樣來標記，包括 i18n:domain 和 i18n:translate 等，如圖25 所示。


▲ 圖25 i18n: 字樣標記的訊息字串

利用 i18ndude 模組，可以協助我們萃取和管理訊息字串，在 develop.cfg 新增一個 i18ndude 設定區段，內容如圖26 所示。執行 bin/buildout -c develop.cfg 後，就可以在 bin 目錄裡找到 i18ndude 工具程式。


▲ 圖26 i18ndude 設定區段範例內容

接著，我們要確認 mysite/eventfolder/configure.zcml 檔案裡，完成 ＜i18n:registerTranslations directory="locales" /＞ 的設定，如圖27 所示。


▲ 圖27 configure.zcml 的 i18n 設定範例

同時也要建立 locales 相關的目錄，它們用來存放 .po 檔案，如圖28 所示。


▲ 圖28 建立 locales 相關目錄

訊息字串的翻譯

首先，使用 i18ndude rebuild-pot 建立 .pot 檔案，它是產生 .po 檔案的基礎，再用 i18ndude sync 建立 .po 檔案的內容，如圖29 所示。注意到 i18ndude rebuild-pot 指令最後接的是一個「點符號」，代表現行目錄的位置。


▲ 圖29 使用 i18ndude 建立 .po 檔案的範例

接著，編輯 locales/zh_TW/LC_MESSAGES/mysite.eventfolder.po 的內容，除了記錄人員和時間的資料外，就是要按 msgid 的英文字串，在 msgstr 填入對應的中文字串。如圖30 所示。


▲ 圖30 編輯 .po 內容的範例

編輯完成後，再用 msgfmt 指令把 .po 檔案編譯成 .mo 檔案，指令細節如圖31 所示。


▲ 圖31 使用 msgfmt 編譯 .po 成為 .mo 檔案

重啟系統後，就可以看到上述訊息翻譯的成果，如圖32 所示。


▲ 圖32 mysite.eventfolder 訊息中譯範例

結論

我們示範了幾個展示多媒體的模組，更多應用，留待讀者探索，例如，想要線上顯示 PDF 檔案的話，可以安裝 wc.pageturner 模組。有了圖片和影片的展示模組，結合 Faceted Navigation 之後，就可以做到批次顯示多媒體的搜尋結果。

訊息字串的中文化，需要建立 .po 檔案並進行編譯，如果想把內容也進行中文化，就得借助 Products.LinguaPlone 模組。另外，JavaScript 檔案也有獨立的訊息中文化方式，必須在 browser/configure.zcml 檔案裡指定要額外讀取的 .js 檔案位置。

下次，我們將介紹外部資料庫的連結方式，讓 Plone 的整合功能更上層樓。

[自由專欄] 自由的危機與維基的自由

Reke／文 2011-07-13

近日，中文維基百科進行了一項管理員的解任案表決，最後反對方以些微的票數否決了提案。這次的罷免案牽扯極為廣泛，包括管理員對條目的刪除是否妥當、維基百科的討論是否應該擁有絕對的言論自由，以及維基社群是否應該引入民主制度，都在罷免案進行的過程中產生了極大的爭論。

被誤解的自由維基

維基百科的 Slogan 是「自由的百科全書」，首頁掛著「海納百川，有容乃大」的訓言。這種簡短的口號相當有力，但是也經常導致誤會。在英文裡 Free Software 的 Free 經常被誤解為「免費」而不是「自由」，中文裡的「自由」固然沒有雙關語的困擾，但是也常引發以下的誤會：

誤解一、認為維基百科對任何看法都是可以收納的。此誤解發生在許多新手身上，特別是被自由理念吸引，而亟欲為某些弱勢團體發聲的編者身上。他們經常發生幾種情況，導致編輯被取消或是條目被刪除，最後引起糾紛。這些情況包括：加入沒有可靠來源的資料，並宣稱來源是被「打壓」才無法透過可靠媒介發表；以帶有批判意味的文字撰寫條目，試圖彰顯正義；或是加入自己原創的研究，並宣稱其所做的考證才是真理，可查證的主流說法是以訛傳訛。

誤解二、認為維基百科應該有高度的言論自由。在社群討論的場合可以開啟任何討論話題，提出任何提議。即使這些話題只是煽風點火，無助於百科的編寫，也應該被保留。

誤解三、認為維基百科應該有自由國家裡的一切制度。如要求擁有「民主」表決的權利；或是誤將「方針」與「指引」（這兩項在維基中，可以視為規範）當成法典，要求管理員或社群不得禁止方針或指引中未明文規定的不妥行為，實行所謂的「法治」。有此類誤解的維基人，特別容易對中國大陸出身的管理員產生敵意，將其不在方針規定範圍內的作為解讀為「和諧、獨裁」等等。

事實上，維基百科只是一部百科全書，既不是論壇也不是「民主試驗場」。維基百科的「海納百川」，不意味著可以收納一些極端言論，或是明顯被科學否證的胡言亂語。全面的自由，只會使維基百科成為混亂的論壇空間以及真偽難辨的知識+，形成知識分享的危機。

維基百科的自由

在加入維基百科編寫行列的同時，要正確的體認維基百科的「自由」，才能夠讓這樣一個空間真正發揮它的功能。這些自由包括：

1. 編寫的自由。在維基百科上，「編寫」是自由的，任何人皆可以參與，無需掛上專家的頭銜，甚至連註冊維基帳號都不需要。除此之外，因為 Wiki 是個多人協作的系統，又具強大的歷史版本儲存功能，編寫者的技術門檻極低－很多新手因為不熟悉 wiki 語法而裹足不前，但事實上，新手可以只添加內容、將語法問題留給其他老練的編輯者來補充完成。

2. 使用與分享的自由。維基百科採用的是 CC-BY-SA 3.0 與 GFDL 雙授權，在合乎授權的情況下都可以自由的分享、應用，包括引用內容，甚至商業出版。

理解了維基百科的「自由」所指何物，才能抱著正確的理念進入到維基的社群。在面臨眾人協作過程中難以避免的磨擦時，也才能夠基於維基精神，與其他編者在良好的互動中找出共識。畢竟維基計劃的成功，重視的是團隊戰力，為了無關百科協作的「自由」而產生紛擾，社群為了爭議爭執而不是共同合作，並不是有心貢獻知識的編者所樂見的。

▲ 圖1 香港與中國社群在罷免案中形成嚴重對立（本圖截自 http://zh.wikipedia.org/wiki/File:Shizhao_RFDA7_votelocation_bar.png，原圖版權由作者  Waihorace 採 CC-BY-SA 3.0 授權釋出）

作者簡介

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

[企業應用] 從 Red Hat 變更 RHEL 釋出方式來探討 GPL 對原始碼範圍的定義

曾義峰／文 2011-07-12

筆者發現台灣目前多數開發者及公司，對於 GPL 授權原始碼的定義範圍不甚清楚，結果導致商業模式的情勢錯估，在極端的狀況下，有時後果甚至反而比完全不採用自由／開放源碼軟體進行產品開發的商業策略還要糟。有鑑於此、在本篇文章中，我們可以從 Red Hat 去年 11 月釋出的 RHEL 6 (Red Hat Enterprise Linux 6) 一例中，進行自由／開放源碼軟體商業模式的初步探討，並一窺軟體社群對於 GPL 原始碼範圍寬嚴有別的認知態度。

成功的自由／開放源碼軟體商業模式

根據市場研究機構 Gartner 於 2011 年 4 月 28 日的研究數據顯示，Red Hat 在 2010 年的營收達到 6.1 億美元，比 2009 年還高了 18 個百分點。這無疑地證明了 Red Hat 在採用自由／開放源碼軟體的企業裡，是在商業營利模式上發展良好的一個成功範例。Red Hat 的營利模式主要靠的是訂閱模式 (Subscription Business Model)，也就是說，讓使用者向其購買技術支援、客製化需求與自動化的穩定升級服務等等，來獲取利潤。細部來說，這些服務方式又劃分為電話支援 (Phone Support)、網頁支援 (Web Support) 及事件處理上的持續支援 (Unlimited Incidents)。

然而、成功的案例往往會吸引其他的競爭對手搶食利益的大餅，Red Hat 歷史上的競爭對手中，包括過去同樣善用自由／開放源碼進行商業服務的 Novell（已於 2010 年 11 月 23 日被 Attachmate 公司收購）。因此，為了在此高度競爭的環境下保持獲利，Red Hat 與 Novell 等公司，不約而同地投入了大量的人力，透過主動貢獻相關自由／開放源碼軟體原始碼的方式，以商業模式驅動的態度、將這些程式碼回饋給社群夥伴進行研究和開發。也正因為如此，可以說 RHEL 的成功，有很大一部份是奠基於自由／開放源碼軟體，透過企業團隊與社群夥伴的良性互動，提昇了 RHEL 在執行效能與穩定性方面的表現。而按照 GPL 授權條款的要求，Red Hat 相關的程式改作也必須提供原始碼，並且同樣依照 GPL 律定的授權方式釋出，這當中亦包括了 Linux Kernel 方面的改作。

這樣的雙向回饋系統（社群、商業模式雙贏），初期促進了 CentOS 及 Scientific Linux 發行套件的誕生。這些發行套件直接取用了 Red Hat 釋出的原始碼，並將其中屬於 Red Hat 公司本身著作權的軟體去除後，再重新編譯、整理，最後再行對外散布。就筆者所知，RHEL 中完全屬於 Red Hat 著作之軟體並不多（因為基於 GPL 的互惠性原則，高度相依於 GPL 授權元件的軟體，在後續散布時也必須同樣以 GPL 進行授權。），因此即使在 CentOS 及 Scientific Linux 在去除掉這些程式碼後，仍然保有絕大多數 RHEL 的功能。雖然從表面上來看，CentOS 及 Scientific Linux 這種透過少量自我努力，卻可以贏得多數 RHEL 既成成果的方式，似乎對於 Red Hat 的持續獲利會有某種程度的影響，但其實實際上的效果有限，主因是 CentOS 及 Scientific Linux 兩者皆為社群驅動的發行版本，非屬於營利公司推行的商業版本，所以就市場利益的競合上對 Red Hat 尚無太大的影響。

然而、真正壓垮駱駝的最後一根稻草的不是別人，正是 Red Hat 在商業服務上的長期合作伙伴－Oracle。Oracle 試圖改作 RHEL，並重新發行了屬於自己的 Unbreakable Enterprise Kernel。Oracle 對外宣稱 Unbreakable Enterprise Kernel 完全相容於 RHEL、但執行效能更快，並且對於 Oracle 其他軟體服務方案的支援亦更好。從道德層面來說 Oracle 的作法不無爭議，但從 GPL 授權條款方面來看，其對於 RHEL 中以 GPL 授權的部份，確實具有合法的改作以及再散布的權利。那麼、面對 Oracle 這樣來勢洶洶的直接挑戰與威脅，Red Hat 就一個營利公司的本位，亦不得不調整作法，設立出新版原始碼釋出的「保護政策」。在 RHEL 5 以前，Red Hat 對於 Linux Kernel 相關的原始碼皆是採用獨立原始碼修正 (Diff Patch) 的方式釋出，此種方式的好處，是讓開發者可以方便知道該改作的功能、目的及範圍，所以、對於像 Oracle 這種搭便車 (Free Rider) 的商業公司，也可以很方便的得知哪部分是他想要的，哪部分是他所不需要的，很快的就可以根據 RHEL 這些程式原始碼，重新改作散布其自己的商業發行版本。

於是在商業模式受到 Oracle 刻意衝擊之後，Red Hat 從 RHEL 6 開始，採用了較不便利後手修改的「保護政策」，其將 Linux Kernel 相關的原始碼改採「完整源碼」的方式釋出，不再延用原始碼修正 (Diff Patch) 的作法，也不再以獨立修正的檔案呈現。這樣的方式雖然令搭便車的人不再方便利用，但也同時讓社群開發者難以快速得知 RHEL 新版本的改作功能、目的及範圍！

讀者有興趣的話，可以參照下列的方法來自行感受 RHEL 5 與 RHEL 6 前後的差異。

首先下載 RHEL 5 的 Linux Kernel 原始碼包，下載位址於 http://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/kernel-2.6.18-92.el5.src.rpm。

及 RHEL 6 的 Linux Kernel 原始碼包，下載位址於 http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/kernel-2.6.32-71.el6.src.rpm。

在 Linux/BSD 下解開此兩個檔案還需要額外安裝 rpm2cpio 軟體，在 Debian/Ubuntu 的讀者，可以使用 apt-get 或 Synaptic 圖形化的安裝介面，下述範例為使用 apt-get 指令列的安裝方式：


▲ 圖1 以 apt-get 指令在 Debian/Ubuntu下安裝 rpm2cpio

安裝完成後，可以直接對該兩個 Linux Kernel 原始碼包解壓縮。


▲ 圖2 輸入指令解壓縮 Linux Kernel 的原始碼

解壓縮完成後，即可看到兩者的差異，例如 RHEL 5 的 Linux Kernel 原始碼包資料夾解壓縮後顯示如下。


▲ 圖3 RHEL 5 的 Linux Kernel 原始碼包解壓後顯示圖

這是 RHEL 6 的 Linux Kernel 原始碼包資料夾，


▲ 圖4 RHEL 6 的 Linux Kernel 原始碼包解壓後顯示圖

其中的 linux-2.6.32-71.el6.tar.bz2 就是之前稱的「完整源碼」，對這個檔案再次解壓縮後，呈現為以下的圖示。


▲ 圖5 RHEL 6 內 Linux Kernel 「完整源碼」解壓後目錄結構顯示圖


從 RHEL 6 的保護政策探究軟體社群對於 GPL 原始碼範圍的認知態度

不可諱言的，許多自由／開放源碼軟體的社群開發者，對於 Red Hat 改採的「原始碼保護政策」不滿，認為這樣的行為違反了 GPL-2.0 授權條款對於原始碼範圍的要求。然而、是否這樣的行為嚴格違反了 GPL-2.0 定義範圍，其實不同的評論者有著寬嚴不同的解釋與看法，因為在 GPL-2.0 授權條款中對於原始碼的定義為：

"The source code for a work means the preferred form of the work for making modifications to it."

這中間存在一個爭議點，那就是對於何謂 "Preferred Form" 的定義界限，產生了「一個條款，各自解讀」的情形。根據多數軟體社群開發者的認知（其中包含 Linux Kernel 的主要貢獻者們），RHEL 6 這種只給最終原始碼的方式，可以說仍是一種「混淆式 (Obfuscated)」的散布，並不能夠完全符合 GPL-2.0 條款裡關於 "Preferred Form" 一詞的定義。然而、就文義解釋來說，GPL-2.0 授權條款對於 "Preferred Form" 也沒有更多的描述與更清楚的補充定義，所以在法律論理上，這個爭議仍然處於不易輕易辨別的灰色地帶。因為即使 RHEL 6 只給使用者最終一體呈現的「完整源碼」，但在實質上並不完全妨礙其他人接續改作與散布 - "Making Modifications"，只是與之前 RHEL 5 的釋出方式相較，變得沒有往常那般方便與直覺。

從這裡還可以延伸討論另一個有趣的問題，那就是若原始碼經由「混淆器 (Obfuscator)」混淆後再行散布，是否也依然符合 GPL-2.0 授權條款對於原始碼的要求呢？這個問題其實也是台灣許多公司或開發者早期認為可行的方法之一，然後、從這幾年層出不窮的案例來看，刻意混淆 GPL 授權程式碼的行為，其實並不能夠在 GPL-2.0 條款的文義解釋上站得住腳。

首先，經過「混淆器」的程式原始碼，一定會讓程式開發者難以辨識，而既然連程式開發者都難以辨識這些程式碼，那麼當然它不會被認定為是符合 GPL-2.0 定義範圍的 "Preferred Form"，因為程式碼在這樣的狀態下，程式設計師根本無從改作 - "Making Modifications"。

例如以下這個經由混淆器處理過後的範例:

static  int  g1lF4=(0x1684+2625-0x20c1);void  zls_R(const  char*DI9U1,const  char*
I9N5k){fQypt((0x139+8656-0x2306),DI9U1,I9N5k);
}void  fQypt(int  jcYPq,const  char*DI9U1,const  char*I9N5k){char  kQy2g[
(0x99c+5415-0x16f3)];T6tLr  lnZ32=tPnbJ(GWScy);fr2Mc(kQy2g,sizeof(kQy2g),
"x25x73x3ax20x6cx65x76x65x6cx20x25x64x20x61x74"
"x20x25x73x3ax20x25x73",AaJDs(&lnZ32),jcYPq,DI9U1,I9N5k);if(jcYPq>=g1lF4)
Xz_15.tB_We(kQy2g);oIk3S.tB_We(kQy2g);}

上述的例子讓一般程式設計師難以直覺認知這段程式該怎麼改作，從何改作，因為程式原始碼在解釋上，就是讓程式開發者了解並據以後續修改程式的最佳格式，透過混淆器的遮蔽，上述 GPL-2.0 條款對原始碼的定義與內涵完全都消失了。當然，如果大部分的程式設計師可以很直覺的改作上述混淆過的程式，那麼也許混淆者還可以試著主張這仍然是個符合 "Preferred Form" 定義的程式原始碼；但若是多數的程式開發者都持反對意見，那麼這類的混淆行為就很明顯是不符合 GPL-2.0 的相關規定了。