關於本報

自由軟體鑄造場電子報
報主：中央研究院資創中心
創刊日期：2004-06-03
發報頻率：雙週刊
訂閱人數：3,349
官網：
無

近期電子報


訂閱便利貼


將貼紙語法置入您的網站或部落格當中， 訪客可以輸入mail取得認證信，並按下確認連結後， 快速訂閱您的報紙。
預覽圖
訂閱自由軟體鑄造場電子報報
自由軟體鑄造場電子報
-----------------------------------------------------------------------------------------------------
Plurk FaceBook Twitter 收進你的MyShare個人書籤 MyShare
  顯示內嵌語法

自由軟體鑄造場電子報
發報時間: 2010-11-23 16:00:00 / 報主:OSSF
［公益聯播］用「愛」點亮「礙」的成長能量~「十方」需要您伸出愛的雙手，扶持慢飛天使
本期目錄
．[法律專欄] 自由軟體專案授權方式的轉換（上）：不得撤銷原授權條款
．[名家專欄] （商業炒作之前的）雲端簡史－PaaS 篇
．[自由文化] 開放近用還需要開放什麼?
．[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
．[源碼報報] 美政府單位僅考慮微軟方案 Google 提出控告
．[源碼報報] Oracle 計畫提供免費和付費兩種 Java 虛擬機器版本
．[源碼報報] Java 技術相容認證受阻 Apache 揚言離開 Java標準制定組織
．[源碼報報] 中國移動加入 Linux 基金會
．[新進專案] 新進專案列表 11/22
．□ 關於本報 □
[法律專欄] 自由軟體專案授權方式的轉換（上）：不得撤銷原授權條款
葛冬梅、林誠夏/文　2010/11/22

筆者在工作上，接觸過不少國內的軟體開發者有這樣的疑問：自己的程式 A（以下簡稱 A）採用甲款自由軟體授權條款釋出，但是之後想要採用另外一份不同的乙款條款來授權的話，是否可以將專案原來的甲款授權方式撤銷 (revoke)，然後改為新的乙款授權條款來授權？雖然部份授權條款並沒有明文說明這方面的規定，目前也沒有司法判決明確禁止這樣的行為，不過因為自由 軟體授權條款具有授權給公眾利用後不間斷散布的特性，因此從條款的授權架構與軟體社群的運作習慣分析之，筆者並不認為自由軟體授權專案具有嗣後撤銷性。

本文將以目前最廣為應用的自由軟體授權條款 GPL 第 2 版（以下簡稱 GPL2）為例，說明公眾授權條款的特性以及嗣後撤銷授權所可能產生的問題，以解釋為何自由軟體著作權人不宜逕行撤銷原授權，而必須採取其他的方式轉換專案的授權方式。

【依照目的性解釋 GPL2 並不允許撤銷授權】

詳細翻閱 GPL2 的條款內容，可以發現，這份條款裡面並沒有任何明示允許或明示禁止權利人撤銷授權的文字敘述（但 GPL3 已有明文禁止撤銷授權的規定，註一），但是從目的性解釋的觀點來看，GPL2 規劃的是一種「權利散布嗣後不會被撤銷的狀態」，我們可以從 GPL2 第 4 條的授權規定了解這個觀點（註二），在 GPL2 專案的散布過程中，若是中間散布者因不遵守 GPL2 授權條款的規定而罹於「失權 (right termination) 」，那麼經由失權者得到此一 GPL2 專案的後續使用者，依 GPL2 第 4 條的規定，並不會因為上游散布者的失權，而導致自己的授權也受到影響。從這點可以看出，GPL2 授權條款預設的是一種「不會向後失效的授權態樣」，所鼓勵的是「程式碼被不斷傳散利用」的立場，從這樣的目的性解釋來看，GPL2 這樣的自由軟體授權條款，自然不當允許權利人在將程式碼向公眾進行廣泛授權後，又復自行撤銷授權。

【撤銷 GPL2 在實際運作上將引發的問題】

而一般法律上所謂的撤銷授權表示，是指將 A 的狀態恢復到跟沒有採用 GPL2 授權之前一樣，也就是說，若同意公眾授權條款的權利人能夠嗣後撤銷其授權，則此 A 專案在法律狀態上自始都沒有以甲授權條款散布過，這樣的事後撤銷行為，將會涉及非常多的使用者與開發專案，範圍之廣可能會引發相當大的問題。這是因為 GPL2 允許得到 A 專案的使用者可以自由地使用與散布程式，因此在權利人意圖撤銷 A 專案原先的甲授權狀態時，該專案可能已經被廣泛地散布到全球各地，所以當 A 的授權狀態改變時，所影響到的使用者範圍將是全球性的，此外許多使用者與開發者現實上根本無由得知 A 專案的甲條款授權條件已被撤銷，所以若是此 A 專案的權利人能嗣後任意撤銷原專案的授權，亦將連帶造成許多善意使用者在不知情的狀況下侵權利用該專案。

而任意撤銷自由軟體專案授權 會帶來的另一個問題，則是影響其他自由軟體專案的開發穩定性。因為 GPL2 允許自由修改，所以 A 極有可能已經被其他的社群開發者加以修改後，跟其他的程式結合成為一個更大的自由軟體專案。一旦 A 專案的權利人嗣後自行更改授權，這些利用到 A 的自由軟體專案，可能因為更改後的授權條款與專案中其他程式的授權內容不相容，進而需要費時耗工調整軟體架構、改寫授權狀態不再穩定的程式碼。因此撤銷原 自由軟體專案的授權方式，將會影響到原合法利用 A 專案的自由軟體專案與這些專案的使用者。此外，由於自由軟體具有站在巨人肩膀上進行接力開發的特性，所以因事後撤銷授權所可能引發的授權紊亂將是多不勝 數，此為第二個需要慎重考量的重大弊病。

【使用者的信賴共識應該受到保護】

GPL2 自 1991 年發佈以來，至今已經過了 19 個年頭，在這期間全球自由軟體的使用者已經發展出一種對於 GPL2 授權態度的信賴感：只要利用到 GPL2 的程式碼，就表示不需要支付著作權的授權金費用，可以自由使用、修改與散布程式原始碼，並且不需要擔心著作權人是否會改變心意、撤銷授權。這樣的信賴感並 非僅存在一年、兩年，或者是僅在少數人身上，而是經年累月地被絕大多數的軟體社群參與者所深信不疑著。因此雖然 GPL2 的授權文字並沒有明文禁止著作權人撤銷其授權的意思表示，但是筆者認為自由軟體透過全球性的長年實際運作，所產生跨國性的信賴共識必須要加以肯定，並受到 保護，否則對於長年利用 GPL2 程式的使用者與其他自由軟體專案的開發者來說，將會遭受不合理的突襲，而對於那些無法得知授權狀態已經改變的使用者來說，這也是不公平的對待。

此外，在我國民法關於贈與契約的規定中，也可以看到信賴利益保護的類似規定。GPL2 並不是民法定式的有名契約，但若將其與附負擔的贈與契約相比較，此兩種型態的法律行為裡，都有著當事人一方擔負一定責任後即可無償受惠的關係，因此我們可 以參考贈與契約的相關規定來類推 GPL2 的嗣後撤銷性：依據我國民法規定，若丙表示要將某一幅名畫送給丁，只要丁已經拿到這幅畫，原則上，丙就不能因為後悔或需要賣畫償還卡債等等理由，來要求丁 歸還已經因贈與而收受的名畫，而若丙還沒有將畫拿給丁，則原則上丙可以在交付前撤銷這個贈與契約。但是，交付前的撤銷亦有其例外規定：若是丙丁之間的贈與 契約經過公證，也就是經過一個公開確認的程序，那麼甲是不能因反悔而嗣後撤銷這個贈與契約的，即使此時畫作並未交付，也一樣不能撤銷（註三）。所以由此論 述，既然法律可以保護丁對於公證過贈與契約的信賴，讓丁不用擔心丙會隨時反悔、撤銷契約，那麼透過近二十年全球自由軟體社群實際運作而產生「著作權人不會 嗣後撤銷 GPL2 授權方式的信賴共識」，也就更應該要被跨國性的尊重與保護。

【自由軟體專案的授權方式原則上應禁止被嗣後撤銷】

前述關於 GPL2 授權禁止嗣後撤銷的論理，原則上也可以套用到其他的自由軟體授權條款上，例如：LGPL、BSD、MIT 與 Apache 2.0 等。但以上的立論並不表示，自由軟體專案的權利人嗣後完全無法異動該專案的授權模式，實務上若是著作權人對於原本的程式想要採用另外一種授權方式時，通常 會將程式碼適度修改、更改該專案的版本號後，再透過其他的授權條款來釋出這個新版本的程式碼，例如原本的 A 是 1.0 版，經修改之後成為第 1.1 版，此時權利人能夠使用其他的自由軟體授權條款或收取授權金的商業授權方式來授權 1.1 版，但原 1.0 舊版則延續以甲條款來進行公眾授權，這樣的話，就可以在顧及使用者對於自由軟體授權信賴共識的前提下，也達到權利人嗣後轉換專案授權方式的目的。


註一：GPL3 第 2 條第 1 項第 1 句："All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met."

註二：You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

註三：請參閱我國民法第 408 條第 1 項：「贈與物之權利未移轉前，贈與人得撤銷其贈與。其一部已移轉者，得就其未移轉之部分撤銷之。」，同條第 2 項規定：「前項規定，於經公證之贈與，或為履行道德上義務而為贈與者，不適用之。」
[名家專欄] （商業炒作之前的）雲端簡史－PaaS 篇
洪朝貴/文　2010/11/11

◎ 本篇文章傳達筆者意見，不代表自由軟體鑄造場電子報立場，回覆意見請見部落格原文網址：http://blog.ofset.org/ckhung/index.php?post/10ad。

本文延續 SaaS 篇的雲端簡史，接續探討 PaaS (Platform as a Service) 的歷史，並解釋：「為何絕大多數組織企業目前沒有能力接受 PaaS 的好處？」

最早的 PaaS，可能是出現在 1976 年前後網路協定文件 RFC 707 裡面的 remote procedure call 概念。筆者學生時代較流行的實作，是 Sun RPC。SaaS 篇裡面所談到的 NFS 網路檔案系統應用，就是用 Sun RPC 開發出來的。1990 年代中期的 Microsoft RPC/DCOM 延續這條線，但太複雜，且一開始並不開放，所以最後走入死巷。反而是從頭就開放的 Sun RPC，後來改名為 ONC RPC，現在還有人在用它來開發－主要用處是將過去陳年的 RPC 應用軟體搬到新的環境。
第二波廣泛流行的 PaaS，是始於 1998 年的 XML-RPC。當時 http 已經成形，UserLand Software 與微軟合作設計這個開放的協訂。後來演進成 SOAP (Simple Object Access Protocol)。

但是 SOAP 過於複雜，於是在 2000 左右，出現了 REST (Representational State Transfer) 類型的 PaaS web services。與其說它是一個標準，不如說它是一個設計風格。REST 的設計風格，採用既有的 http 1.0/http 1.1 協定，而不訴諸複雜的 XML 內文定義，以簡單的網址 (URL)「呼叫」或「取用」遠端的資源。從一些分析看來（2005 年文章、2009 年文章、google 宣佈其搜尋引擎介面捨 SOAP 就 REST）REST 逐漸取代 SOAP，成為 PaaS 的主流。這與 "small pieces loosely joined" 小小片、鬆鬆接的網路演化趨勢，可能有關。

一 個 PaaS 單獨使用，通常看不太出 PaaS 的明顯好處。對於終端用戶而言，SaaS 才是終極目標、才具有最直接的使用價值；但是某一個 PaaS 若有可能的熱門應用，大約早就有人（可能很多組人馬）做出相對應的免費 SaaS 實作了，又何必自己購買複雜的 PaaS 服務再自己找程式設計師辛苦撰寫？真正有趣、特殊、可以考慮投資人力與金錢的 PaaS 應用，經常來自於同時混搭 (mashup) 採用來自兩個或兩個以上 PaaS 網站的服務。（一個簡單的範例：混搭 google 地圖與行事曆） ProgrammableWeb 這個站的列表與矩陣，搜集了許多提供 PaaS 的網站，以及兩兩組合的應用範例網站。從 way back machine 可以查出來：此站建立於 2005 年 10 月左右。從一個 26x26 的矩陣，成長到今日兩千多個 PaaS 服務、五千多個混搭，這是每一位 PaaS 程式設計師都應該要知道的網站。（當然，那時候還沒有 PaaS 這個名詞。）再以其中的一行（或一列）為例，Google Maps Mania 專門報導 google 地圖與其他 PaaS 的混搭，這也是 PaaS 程式設計師需要知道的重要網站。


談完歷史，再來提一些主觀的建議。

絕大多數中小企業，並不需要 PaaS。
採購 PaaS 就像是採購生食，還需要有專職的廚師將它調理成終端用戶能夠操作的 SaaS。對於絕大多數中小企業而言，直接選用現成的 SaaS（例如 wiki 或 google doc）比較省錢省事。

可能可以受惠於 PaaS 的組織企業當中，絕大多數沒有能力改變工作文化、導入 PaaS。
舉一個最簡單的 PaaS 的例子：混搭訂閱多個 rss。 這對於學校很有用：各個處室自己盡管公佈新聞；混搭之後可以放在學校首頁。它屬於最簡單的 REST 類型 PaaS，程式碼超短。如果處室用部落格取代既有的複雜「公告資訊系統」，並善用標籤，甚至還可以推出「訂閱混搭過的標籤」的服務－例如學生可能對全校所 有處室科系含有「工讀」機會的混搭標籤，會很有興趣。但是過往一、二十年「中央極權」、「緊密整合」、「與『小小片，鬆鬆接』的網路趨勢完全背道而馳」的 資訊系統文化習慣，讓這樣的建議在既有的行政體系底下變得幾乎不可行。

有能力改變工作文化、導入 PaaS 的組織企業當中，絕大多數的場合會站在用戶端（呼叫端）的位置。
例如先前 google 地圖與行事曆混搭的例子，我就是站在用戶端（呼叫端）的位置。此外，要進行這種混搭，組織內需要有某種程度的程式設計人員。而且，最好盡量採用列入 ProgrammableWeb 的成熟、熱門、公開的 PaaS，比較有長遠的保障。

可能可以受惠於 _伺服端_ PaaS 的組織企業，不需要購買 PaaS 工具。
這 些組織企業，應該要有工程師群，他們對於雲端技術及 REST 風格的熟悉程度遠超過筆者。如果現成的雲端工具（例如 Apache 的 hadoop）不合用，自行替現成的雲端工具開發模組，遠比採購冷門的專屬 PaaS 更有保障－有國際的開發社群可以互相切磋。附帶一提：什麼樣的組織企業，才會需要 _伺服端_ PaaS？如果組織本身之外，沒有其他人使用你所提供的 PaaS 服務，那麼可能要檢討：這個工作是否根本用現成的 SaaS 自由軟體就可以解決？真正有意義的 _伺服端_ PaaS，應該要能夠被列入 ProgrammableWeb。不過，一旦被列入，而且真的吸引到外部的用戶端（呼叫端）使用者， 那又代表什麼呢？請記得：這裡的每一位「用戶端（呼叫端）」，本身都是一個網站，都在一個網頁伺服器上執行。也就是說，你的用戶，會有很多用戶！這有兩個 推論，第一：對於這樣的組織企業來說，行銷／曝光率會是分享 PaaS 的一個很大的收穫。第二：不是很多組織企業有能力做到這一點。Plurk、Twitter 所提供的 PaaS，可以嵌在網頁上，他們就屬於這一類的例子。當貴組織真的能做到這一步，相信您對於注意力經濟的了解程度，早就己經超越筆者，也早就不需要讀筆者「破除雲端炒作」的文章了。

所以，最後一句話還是：想導入雲端？請先從最簡單的「wiki 部分取代 office」這個免費、自主、投資最小、效益最大的 SaaS 私有雲開始實驗，把大部分的資源投入行政文化改造，循序漸進比較實際吧！
[自由文化] 開放近用還需要開放什麼?
張朝欽／文　2010/11/18

開放近用運動 (Open Access Movement) 推動的方向，正式定調於 2002 年的《布達佩斯開放近用提議》（Budapest Open Access Initiative），現今主要的實施策略有二：其一為透過開放近用期刊（OA Journal）或俗稱的 Gold Road，試圖脫離現有的學術期刊商業模式，提供給社會上所有使用者線上免費的學術期刊電子論文；其二為機構典藏 (Institutional Repository) 或俗稱的 Green Road，試圖以大學或研究機構為單位建立電子典藏庫，將學術文獻、作者自我典藏的文獻，甚至論文的預印本存放在典藏庫中，並且開放給全體社會取用。基本 上這兩種策略都是希望透過網際網路的存取與搜尋技術，並排除財務障礙和法律障礙，讓學者或社會人士都能有免費取得學術文獻的管道（劉聰德，張朝欽 等，2010）。

開放近用運動最主要的成就，在於它試圖讓學術界擺脫商業出版社的綁架，讓研究論文的閱讀和學術溝通不再是昂貴的、受限的，其最大的獲益者為學校圖書館和學術文獻閱讀者；但是就開放近用的開放對象 ─ 學術論文而言，它本身還是沒有經歷到所謂網路的集體智慧或是論文內容的修正改作。如果我們用自由軟體運動過去的發展經驗或以創用 CC 的精神，來期許開放近用在未來的發展方向，有兩個可能發展可以提出來作為參考。

第一點，開放近用論文在出版或是存放入典藏庫之時，同時讓它採用創用 CC 授權條款來釋出。這樣的作法是將開放近用的文章，也就是把學術研究的成果當成標的物，允許繼續的使用、複製、修改和分發來共創知識價值。這樣的作法接近於 某些學術社群在創造知識的手稿階段之時，讓外界人士在開放網站的共通文件上給予修改和評論。

第二點，如果將論文本身視同自由軟體，論文的內容包含物則視為原始碼的開放，來推動學術論文的全面開放。我們認為學術研究的產出，論文出版僅為符碼化知識的其中一種（即俗稱的白色文獻，white literature），除了論文本身的文本 (text) 之外，在創造論文的工作階段當中所產生的資料、材料、軟體、內部報告、動用到的資料庫以及所蒐尋到的文章和資料等（俗稱的灰色文獻，grey literature），這些灰色文獻事實上在該研究過程當中扮演著相當重要的 know-how 角色，缺乏了它們，論文所表達的研究成果或實驗過程是難以重製的。如同 Jeffery 所指稱：研究活動應該包括了一系列工作流的產出，從初始概念、計畫提案、內部報告到最後的出版，出版也包括了產出的資料、軟體和交互引文，這些都應該被保 存、記錄下來並繼續傳播（Jeffery，2005）。

自由軟體運動是較早體認到開放軟體原始材料的重硬性，軟體唯有藉由原始碼的開放而能被使用者控制和重覆地複製，該軟體才能獲得修改的自由。從這樣的角度來看研究論文的開放，僅只論文文本的釋出是不夠的，例如論文如果沒有釋出某一圖 表背後的資料集，使用者是難以理解或複製該圖表的產生過程，更遑論去理解一篇包含多個圖表的論文；或者作者僅以參考文獻來交代研究方法和步驟，但是該引文 之文獻卻難以取得。論文的這些灰色文獻如同軟體原始碼般的重要，開放近用論文如果不去開放這些附屬的研究資料，就有如軟體是可供自由使用和複製，但是原始 碼卻沒有開放，所以也稱不上是自由軟體。

事實上開放近用的三個重要國際宣言（布達佩斯開放近用提議、貝色斯達開放近用出版宣言和柏林 宣言：科學與人文學知識的開放近用）都有提及後設資料或論文所有補充資料的開放，特別是柏林宣言列舉了原始研究成果、原始資料、後設資料、素材等的開放。 Open Data 雖不是直接主張研究論文所包含的原始資料的開放，而是主張政府部門所補助的研究資料開放，例如地理資訊、基因組和科學方程式等，然而 Open Data 對於研究資料開放的正當性論證，事實上也同時論證了論文附加資料開放的正當性， OECD 並且也在 2007 年公佈了研究資料近用的指導性原則，作為會員國共同遵守的規範（OECD，2007）。

歐洲即時研究資訊系統（euroCRIS, European Current Research Information Systems）（euroCRIS 2010）所努力的方向較與本文契合；euroCRIS 試圖對歐盟會員國的研究成果（論文出版、專利和產品）等研究資料提出一個共同的資料儲存格式（即CERIF格式），以方便各國之間的資料交換，另外 CERIF 也設計成可以記錄研究計畫、人員、機構、設備等資料，目的就是全面地紀錄一國研發活動的資訊。euroCRIS 是以較全面性的角度來看待研究資訊的儲存和管理問題，特別是從研發補助機構的管理者角度；除了論文出版，euroCRIS 也朝向於去對論文文本以外的資料集（datasets）的蒐集和儲存。

此外由英國 Southampton 大學和美國 Cornell 大學所推動的 The Open Citation Project（OpCit Project 2010），雖然該計畫的終極目標是對引文行為進行分析，然而其中的 Citebase 服務試圖對開放近用的文章進行參考文獻的全文連結，這也說明了：越是在論文全面開放近用和電子化的環境，reference 的全文連結越是容易達成。其實，以目前的資訊科技和網路環境，實用的整合型軟體工具應該可以很快地產品化，對科技研究成果的分享會有立即而明顯的貢獻（劉聰德，2009）。

參考文獻

劉聰德 （2009）。開放近用在資訊化社會的優勢。科技發展政策報導。12 月份，議題觀點。上網日期：2010 年 1 月 11 日。取自：http://thinktank.stpi.org.tw/Chinese/Column/Pages/jessicachen1127.aspx
劉聰德、張朝欽等，（2010）。開放近用的機會與展望。台北：國家實驗研究院科技政策研究與資訊中心編印。http://thinktank.stpi.org.tw/Chinese/WWS/Pages/20101103.aspx
euroCRIS (2010). euroCRIS: Current Research Information System. retrieved on Nov. 10, 2010 from:http://www.eurocris.org
Jeffery, K.G. (2005). CRIS+Open Access = The Route to Research Knowledge on the GRID. World Library and Information Congress.retrieved on Nov. 10, 2010 from:http://archive.ifla.org/IV/ifla71/papers/007e-Jeffery.pdf
OECD (2007).Principal and Guidelines for Access to Research Data from Public Funding. Paris: OECD Publication.
OpCit Project (2010). The Open Citation Project.retrieved on Nov. 10, 2010 from:http://opcit.eprints.org/
[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
翁卓立/文　2010/11/18

http://sites.google.com/site/davidtv/
http://ncu.dl.sourceforge.net/project/pacmanager/pac-2.0/pac-2.5.2-all.tar.gz (443KB)
Debian、 Ubuntu 的使用者，可以在 /etc/sources.list（或是 /etc/apt/sources.list）檔案中加入「deb http://archive.getdeb.net/ubuntu lucid-getdeb apps」，再開啟終端機程式依序執行「sudo apt-get update」、「sudo apt-get install pac」即可進行安裝。

簡介

圖形化的操作介面向來是最具親和力的使用介面，也因為如此，現今大多數的 Linux 發行版本預設都會啟用圖形使用者介面。雖然圖形操作介面的便利性無庸置疑，但不可否認的，在 UNIX/Linux 系統的操作上，有時候直接使用文字介面的終端機，登入主機後直接進行操作，反而是比較快速的作法。畢竟在熟悉指令的情況下，有許多作業只需要在終端機介面 中輸入幾個簡單的指令即可完成，而不必像圖形介面一樣，還得移動滑鼠、按下滑鼠鍵開啟選單，再進行選擇或後續操作。所以許多 UNIX/Linux 的使用者，在熟悉了 UNIX/Linux 系統的命令之後，即使為了美觀或操作方便等理由安裝了圖形介面，平常仍然習慣在視窗介面中開啟終端機程式，並直接以文字介面進行操作。

也因為只要熟悉各種指令的操作與參數，文字終端機介面也可以是相當方便好用的系統操作方式，所以許多人在 Windows 作業系統之中，也會安裝一些 Telnet 或 SSH 的連線程式，以作為遠端連線的應用程式使用。例如 SecureCRT 或是 PuTTY，都是相當知名的 SSH 連線管理程式。前者為付費軟體，後者則是採用開放原始碼方式釋出。但如果要在 Linux 系統之中，使用 Telnet 或 SSH 實現遠端登入的功能，只能開啟終端機程式，並以手動輸入指令與參數的方式執行 telnet 或 ssh 指令，系統預設並沒有像 SecureCRT 或 PuTTY 之類的連線管理軟體。當然，PuTTY 本身是以開放原始碼方式釋出，原始碼之中也提供了 UNIX 版本的相關程式與說明文件。但這需要使用者自行編譯，甚至還需要解決編譯時可能遭遇到的程式庫相依問題。而目前有一部份的 Linux 發行版本，本身的套件管理系統已經整合 PuTTY，例如 Ubuntu 即為一例。所以使用者只要利用套件管理功能進行安裝，即可開始使用 PuTTY。

PuTTY 雖然方便好用，但仍然在功能上有些不足之處。眾所周知，PuTTY 支援 Telnet、SSH、序列埠等各種不同的連線方式，也可以使用公私鑰交換的方式直接進行登入而不需要使用者自行輸入帳號密碼。但除了基本的連線功能以 外，PuTTY 是否還能夠提供其他的功能？舉例來說，是否可以利用 PuTTY 進行 VNC 遠端桌面的連線？或者在連線建立前或連線切斷後，自動執行使用者所指定的程式或指令？在一般情況下，這些功能都是 PuTTY 無法支援的部份。使用者如果希望達到上述功能，只能另求軟體解決。

本文所要介紹的 PAC Manager，便是一套在 GNOME 桌面環境下執行的 SSH 連線管理程式。PAC Manager 乍看之下與 SecureCRT、PuTTY 等知名的 SSH 連線管理程式相當類似，但 PAC Manager 可以提供更多的功能，足以作為 UNIX/Linux 系統中主要的連線管理程式使用，甚至取代一樣有 UNIX/Linux 版本的 PuTTY。事實上，以 SSH 連線管理程式稱呼 PAC Manager 並不是十分正確，因為 PAC Manager 除了提供 SSH 的連線功能以外，還能作為 Telnet 連線程式使用。此外，序列埠傳輸，甚至是 VNC 遠端桌面的連線功能，也都是 PAC Manager 所提供的連線功能之一。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲PAC Manager 的操作畫面（圖一）

與商業軟體相提並論的功能與特色

SecureCRT 之所以能以商業軟體的模式存在，自然是因為軟體本身提供了相當多元化的功能。為了能夠提供 Linux 使用者一個旗鼓相當的類似軟體，PAC Manager 本身除了支援大多數 SecureCRT 所提供的功能以外，還額外設計了許多進階功能。例如最基本的連線功能方面，SecureCRT 可以支援 Telnet、SSH，以及序列傳輸埠的直接連線功能，這些不同的連線方式，自然也能在 PAC Manager 找到。除此之外，PAC Manager 也提供了多頁籤的連線功能，讓使用者可以同時開啟數個不同的連線，並且快速進行畫面切換。除了使用頁籤方式進行連線以外，在開啟連線的時候，使用者也能要 求 PAC Manager 以開啟新視窗的方式執行連線登入的動作。如果不希望所有的連線畫面全部擠在同一個視窗畫面之中，也能使用此種模式加以替代。

PAC Manager 的連線功能一共支援多達八種不同的連線模式，除了基本的 SSH、Telnet 連線功能以外，另外還有 cu、FTP、rdesktop、remote-tty、SFTP、VNC Viewer 等等。其中 FTP、SFTP 都是作為檔案傳輸功能使用，差別只在於使用的協定為明碼傳輸或編碼傳輸。cu 與 remote-tty 可以用來作為序列傳輸埠的監看功能或作為終端機登入功能使用，而 rdesktop 與 VNC Viewer 自然是作為遠端桌面的連接程式使用。

以群組觀念進行管理

一般而言，需要使用連線管理程式的環境，多半是使用者有需要同時連接不同主機的需求。如果主機數量多到一定程度，即使 PAC Manager 提供將主機設定儲存在軟體中的功能，可能也無法在短時間之內快速找到所需要連接的主機名稱。此時可以利用 PAC Manager 所提供的主機群組管理功能，將不同用途或不同區域的主機加以分類，將來要使用 PAC Manager 的主機列表進行連線時，可以先行挑選該主機所屬的群組，再找到該部主機即可直接連線。

除了可以使用群組功能進行連線主機的管理之 外，PAC Manager 本身也提供了許多連線相關的選項，可以讓使用者在執行 PAC Manager 或進行連線時有更加彈性化的選擇。例如在初次連接 SSH 伺服器時，一般的連線軟體都會詢問使用者是否要接受該主機的金鑰，但 PAC Manager 可以設定為自動接受新的金鑰，只是方便之餘，這樣的作法也有些危險就是。此外，使用者也能決定按下關閉鍵時是否要直接關閉 PAC Manager，或是僅將 PAC Manager 縮小至系統列，而非直接關閉。如果將 PAC Manager 縮小放置到系統列，此時也可以直接在 PAC Manager 的圖示上按下滑鼠右鍵開啟 PAC Manager 的操作選單，並直接使用此選單查詢目前已開啟連線的相關狀態，或是進行其他處理。PAC Manager 本身也支援代理伺服器的連線功能，如果需要經由代理伺服器的輔助才能連上遠端主機，也能在 PAC Manager 的設定畫面中加以設定，即可使用代理伺服器進行連線。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲PAC Manager 提供了相當多的功能與設定選項（圖二）

巨集功能與通訊埠轉送功能

PAC Manager 還另外支援了一項相當方便的巨集功能，非常適合經常需要在遠端與本地端執行重覆性工作的使用者加以利用。巨集的功能是先在連線設定畫面中進行編輯，依照指 令的執行需求而設定在本地端的巨集，或是加入遠端的巨集清單之中。在連線成功之後，如果需要執行先前所設定的巨集，只要在畫面上按下滑鼠右鍵，並在選單中 選取已設定好的本地巨集指令或遠端巨集指令即可。舉例來說，假設在遠端巨集中加入「ls」的指令，而在本地巨集中加入「nautilus」指令，則在遠端 命令的選單中選取「ls」，此巨集便會立即在遠端主機執行。如果選擇的是本地命令中的「nautilus」，則會在本地端主機開啟檔案瀏覽器。稍加組合運 用，便能將此巨集功能發揮到極限，並在日常作業中增添不少幫助。

SSH 本身支援通訊埠轉送（Port Forwarding）功能，也就是 SSH 隧道所使用的技術。通常 SSH 的通訊埠轉送細分為三大類，分別是本地轉送、遠端轉送，以及動態轉送。以往在 Linux 系統中，無論是建立何種 SSH 隧道，大多只能直接以指定參數的方式加以建立。但如果使用 PAC Manager，則可以在連線設定畫面中直接進行指定，而且可以一次加入一組以上的通訊埠轉換設定，對於有此一方面使用需求的人而言，會是相當有幫助的一 項設計。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲PAC Manager 也支援 SSH Port Forwarding 功能（圖三）

本地命令與 EXPECT 的支援

除了巨集功能以外，PAC Manager 也另外提供了連線前與關閉連線後的本地命令執行功能，可以讓使用者在登入或登出主機時，同時進行預先設定好的動作。如果有在某個連線的設定畫面中指定連線 前的本地命令執行功能，則在 PAC Manager 開啟連線之前，會先執行這些動作。相反的，關閉連線的本地命令執行功能，則是在連線關閉後才會執行。由於這二項功能都是在連線尚未建立（或連線已被使用者 中斷時）才會執行，自然只能指定本地端可以執行的指令或程式，而不像巨集功能還能區分本地指令或遠端指令。

而在 PAC Manager 建立連線後，還有另外一個對於系統管理員而言相當有幫助的功能，也就是 EXPECT 功能。EXPECT 功能可以在登入主機時，檢查終端機所需出的訊息是否有先前所設定的預期字串。如果出現此字串，即可立即傳送預先設定的指令並加以執行。這些指令的執行地點 為遠端主機，因此只能指定遠端主機有支援的命令。預期的內容除了事先指定的一般字串以外，也能指定為命令提示字元，或是使用者所定義的環境變數以及系統的 全域變數。但目前這個 EXPECT 功能暫時還只能支援開啟連線後所出現的字串，無法在連線後持續進行偵測。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲支援 EXPECT 功能，若在登入主機後發現有預先設定的字串出現，便會立即執行所設定的指令。（圖四）

叢集功能與遠端桌面

如果經常需要登入不同主機，但執行的指令或程式都大同小異的話，或許可以考慮利用 PAC Manager 的叢集主機（Cluster）支援功能。雖然名為叢集主機功能，但 PAC Manager 並沒有辦法支援將不同主機組合成叢集的功能。此功能最大的用途，是經由設定將已開啟連線的主機加入一個虛擬的叢集，接下來只要利用 PAC Manager 在此叢集中的任一個連線畫面中輸入指令，該指令便會自動傳送到已加入叢集的所有主機並加以執行。雖然不能達到真正的叢集運算功能，但這種同時可以針對不同 主機輸入相同指令的功能，也不失為一個方便的工具。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲圖五

無論是 SSH 或 Telnet，都只能以文字介面傳輸指令或程式的輸出資訊。如果要查看遠端主機執行圖形化程式的輸出結果，利用 SSH 或 Telnet 可能都無法非常方便的得到相關的資訊。為了即時監看圖形介面程式的執行結果，使用遠端桌面協定（Remote Desktop Protocol）或是 VNC 會是比較方便的選擇。PAC Manager 亦可支援 RDP 或是 VNC 的連線功能，只要事先安裝 rdesktop 或 vncviewer 等相關的套件，即可直接從 PAC Manager 的連線畫面中加以呼叫，並開啟遠端主機的桌面環境進行處理。

[源碼秘技] 功能強大的 SSH 連線管理程式－PAC Manager
▲圖六

結語

原先 Telnet、SSH 等遠端連線功能，只是為了滿足使用者可以遠端登入並進行操作的需求。但時至今日，早已因為需求的增加而變得有些複雜。無論是通訊埠轉送，或是 EXPECT 等功能，都是為了輔助使用者日常作業所誕生的新技術／新技巧。有了新的需求與相對應的處理技術，自然也需要功能更加進階的管理工具。PAC Manager，便會是遠端連線管理方面相當適合的選擇之一。

作者簡介

翁卓立
逢甲大學資訊工程學系、台灣科技大學電子所畢業，目前擔任韌體研發工作，主要使用 Embedded Linux 進行產品開發。著有「Linux 進化特區：Ubuntu 10.04 從入門到精通」等書。
[源碼報報] 美政府單位僅考慮微軟方案 Google 提出控告
謝良奇／編譯　2010/11/09

Google 日前控告美國政府，為了提升通訊系統功能而提出的報價需求單 (Request for Quotation，RFQ) 中，僅將微軟解決方案納入考慮而排除 Google Apps。這份來自美國內政部  (Department of the Interior) 的 RFQ 要求，解決方案必須是微軟企業生產力線上套件 (Microsoft Business Productivity Online Suite) 的一部份。Google 宣稱，這是過分限制競爭的做法。

針對這一份價值 5900 萬美元的美國內政部電子郵件系統升級合約，Google 控告該單位以專斷方式僅將使用微軟平台電子郵件技術的銷售建議納入考慮。Google 宣稱，假如採用的是非微軟為基礎的建議，可以在遠低於微軟合約成本的情況下，同時仍滿足政府的安全要求。訴狀中詳細記錄了 Google 與美國內政部的會議記錄與通訊往來。其中 Google 試圖說服該單位接受其解決方案。美國內政部則認為微軟提供統一的電子郵件與傳訊功能，以及更好的安全功能，這兩項是其他解決方案供應商缺乏的特點，作為僅 考慮微軟方案的解釋。Google 對此指出，微軟的方案在過去有故障停機時間在內的多項問題，並堅稱 Google Apps 是合適的替代方案。

假如美國內政部最後在法庭上輸給了 Google，對於被全球多數政府單位當作是現存標準選擇的微軟，絕對不是個好消息。假如美國法院裁定 Google 提供的是可行的替代方案，將使微軟感受到壓力。這場訴訟看來可能影響到接下來幾年內會發生的雲端大戰。Google 發言人在聲明中表示，Google 一向支持網際網路和科技領域的開放競爭。一個公平而開放的程序可以為美國納稅人省下幾千萬美元並帶來更好的服務。他們要求美國內政部在選擇技術提供者時， 能給予真實的競爭。

目前看來，對 Google 可能有利的，是一份歐巴馬總統上任不久後製作的備忘錄，並曾被知名網站 TechCrunch 所報導，該備忘錄針對政府過度依賴單一來源合約提出警告，並且指出政府單位開支從 2001 年至 2008 年已經增加了一倍多，歐巴馬將其歸咎於缺乏開放競爭所致。在報告中，歐巴馬要求美國聯邦政府單位力求開放且富有競爭力的程序。

儘管美國內 政部認為 Google Apps 不符安全需求，Google 宣稱該公司擁有政府安全功能，且對於微軟的偏好並非出自安全估量，而是為了限制招標過程。事實上，Google 在 7 月時曾就其網頁生產力軟體釋出特殊版本，以便因應更嚴格的美國政府安全要求。該公司的 Apps for Government 已經獲得美國聯邦資訊安全管理法案  (Federal Information Security Management Act) 的認證，表示可處理標示為敏感的政府資訊。


相關網址：
1.Google 控告美國政府僅考慮微軟解決方案
http://www.techdirt.com/articles/20101030/23442911657/google-sues-the-us-government-for-only-considering-microsoft-solutions.shtml
2.Google 控告美國政府僅考慮微軟
http://www.techspot.com/news/40959-google-sues-us-government-for-only-considering-microsoft.html
3.Google 控告被美政府合約排除在外
http://www.redherring.com/Home/26457
[源碼報報] Oracle 計畫提供免費和付費兩種 Java 虛擬機器版本
謝良奇／編譯  2010/11/11

 Oracle 計畫在未來提供兩種不同版本的 Java 虛擬機器 (Java Virtual Machine, JVM)，一個為免費一個為商業付費版本。這兩套以 OpenJDK 為基礎的 Java 虛擬機器，將取自結合 JRockit 與 HotSpot 的版本。

Oracle 在購併 BEA 時取得 JRockit JVM，這是 Oracle WebLogic Suite 對於 Java 虛擬機器的策略 。使用更為普及的 Hotspot JVM，同樣在 Oracle 購併 Sun 後，被該公司取得。Oracle 在購併 Sun 後，旋即傳出將推出統一的虛擬機器。該公司隨後在 JavaOne 大會的 Java 主題演說中，證實了將整合 Hotspot 與 JRockit JVM，而減少手中虛擬機器數量的計畫。日前在 QCon 舊金山大會一個名為 Java 未來之路 (The Road Ahead for Java) 的議程中，Oracle 的 Fusion Middleware Group 開發副總裁 Adam Messinger 表示，永遠都會有高效能的免費 Java 虛擬機器可用。對於商業版本，他則並未提供定價細節。

同時負責 Oracle Coherence、JRockit、WebLogic Operations ControMessinger 和其他 Web 端產品的 Messinger 指出，預料明年可推出兩套 Java 虛擬機器的初始版本。他說，他們的計畫是這些都匯集到一個虛擬機器中。這個計畫大概需時 3 年才可望完成，不過產品團隊已經完成整併。OpenJDK 是 Java 標準版本 (Java Standard Edition，Java SE) 規格的開放源碼免費實作，採用的是 GNU General Public License (GPL) 授權並附帶有針對 Java 類別庫的連接例外。10 月時，Oracle 與 IBM 曾宣佈在 OpenJDK 專案上合作，改善 Java 社群中創新的速度與腳步。

IDC 分析師 Al Hilwa 觀察到，整合冗餘產品線是 Oracle 於 1 月購併 Sun 後面對的關鍵挑戰之一。該公司也擁有 3 個不同的整合式開發環境 （IDE），首先是被視為策略產品的 Jdeveloper，其次是 Sun 的 NetBeans IDE，該 IDE 也有許多忠誠擁護者，最後則是 Oracle 透過 Oracle Enterprise Pack for Eclipse 加以支持的 Eclipse IDE。此外，Oracle 也有 WebLogic 和 Glassfish 兩套 Web 端軟體伺服器。


相關網址：
1.Oracle 計畫推出商業版 Java 虛擬機器
http://www.h-online.com/open/news/item/Oracle-plans-to-offer-a-commercial-Java-Virtual-Machine-1132041.html
2.Oracle 將提供免費與付費版本的 Java 虛擬機器
http://virtualizationreview.com/articles/2010/11/10/oracle-to-offer-two-jvms.aspx
3.付費版 Java 虛擬機器與開放 Java 虛擬機器提案
http://www.jroller.com/scolebourne/entry/premium_jvm_open_jvm_proposal
[源碼報報] Java 技術相容認證受阻 Apache 揚言離開 Java標準制定組織
謝良奇／編譯　2010-11-16

Updated：Oracle 在 15 日針對 ASF 的聲明發出回應（http://blogs.oracle.com/henrik/2010/11/moving_java_forward_open_response_from_oracle_to_apache.html），為了 Java 未來的發展，要 ASF 不要對新版 Java 採取杯葛行動。

Apache 軟體基金會 (Apache Software Foundation, ASF) 正位於艱難的處境中，這個非營利組織無法認證其開放源碼 Java 執行時期實作 Harmony，相容於 Java 標準。原因就出在 Oracle 拒絕以適當的授權提供必要的測試套件。Oracle 阻擋 Apache Harmony 專案進行標準相容認證的決定，已經和主導 Java 標準化的規則相抵觸，也掀起對於 Java 程式語言開放性的嚴重疑問。

Apache 軟體基金會意圖使用在 Java 標準制定組織 (Java Community Process, JCP) 執行委員會中的席次，否決該程式語言下一主要版本 Java 7 的通過。Apache 軟體基金會正遊說其他有疑慮的 Java 利害關係者，投下類似的反對票以抗議 Oracle 的違反協議。假如 ASF 取得多數優勢，等於是對 JCP 和 Oracle 對 Java 語言的管理，投下不信任票。爭議的核心在於 Java 技術相容性套件 (Java Technology Compatibility Kit, TCK) 的散佈授權條款。證明一套 Java 實作合乎該語言標準所需的 TCK，因為基本上不利於開放源碼 Java 實作者的使用領域 (field-of-use) 限制，而遭受到阻礙。TCK 的授權限制違反了 JCP 管理政策的條款，條款中指出所有相容性測試得以有利於第三方、開放源碼 Java 實作的條款釋出。

外界認為，Oracle 漠視此一政策構成了或可予以提起訴訟的違約行為。假如 Oracle 無法以適當條款提供 TCK 來解決此一問題，Apache 軟體基金會威脅將放棄 JCP。假如該基金會在上述情況下離開 JCP，等於終結了 Java 標榜為開放語言的說法。Java 被接受為標準是基於開放源碼之上，其可信度多數來自於由 Apache 軟體基金會發起的若干 Java 專案。最近該基金會代表以 95% 的得票率，再度獲選進入 JCP 執行委員會。而一名 Oracle 的被提名人則遭到否決。

事實上，Google 大可因為 Oracle 提出控告而不再支持 Java，該公司可說是許多專案運作背後的資金，而 Apache 軟體基金會則是該語言影響力的來源。一旦失去資金和影響力，Oracle 所剩的只是一套所有人都放棄的私有技術，就像 Unisys 在 1990 年代試圖主張對 .gif 格式的權利後所得到的結果。Apache 軟體基金會在聲明中指出，Oracle 因為其 TCK 授權強加不相容於開放源碼或自由軟體授權的額外條款與條件，因而違反 JCP 規則所陳述的合約義務。該基金會作為 Java 規格實作者的權利，一旦不受到 JCP 執行委員會以該委員會能力最大極限加以支持，該基金會將終止與 JCP 的關係。這些權利缺乏積極、強勁且清楚的實施，意味著 JSPA 協議毫無價值，而 JCP 不過是一紙私有文件。Oracle 與購併 Sun 所取得若干開放源碼專案的參與者間的關係，已經因為該公司對於開放管理的敵意而迅速地遭到破壞。例如，OpenOffice.org 眾多開發者已另行分支成立開放源碼的辦公室套件，不少獨立利害關係人也紛紛表態支持許多 MySQL 分支或替代專案，如 MariaDB。


相關網址：
1.Apache 針對 Java 議題向 Oracle 出招
http://www.zdnet.com/blog/open-source/apache-drops-the-hammer-on-oracle-over-java/7757
2.Apache 基金會投 Java 7 反對票，抗議 Oracle 惡行
http://arstechnica.com/open-source/news/2010/11/apache-foundation-to-vote-down-java-7-protesting-oracle-abuses.ars
  • 社群留言
  • 留言報主