第 164 期 自由軟體專案授權方式的轉換（下）：新版本號另以更改後的授權方式釋出─自由軟體鑄造場電子報─智邦公益電子報
enews.url.com.tw · February 07,2012[法律專欄] 自由軟體專案授權方式的轉換（下）：新版本號另以更改後的授權方式釋出
文／葛冬梅、林誠夏
本文上篇的文章連接頁面如右：http://www.openfoundry.org/tw/legal-article-/8195-2010-11-22-18-38-45。
【新版釋出、授權更改】
那麼、既然我們無法用事後撤銷的方式來改變已經釋出的自由軟體授權狀態，當日後專案有授權轉換的需求產生時，究竟應該透過怎麼樣的做法來達到授權變更的目的呢？目前實務上推行的方式，簡單來說就是八個字：「新版釋出、授權更改」。
顧名思義，「新版釋出、授權更改」指的是利用專案釋出新版本號的軟體時，為此新版本號選用更改後的授權條款，這樣的作法並不會影響原釋出版本的授權狀態，但透過新版本號釋出的軟體程式碼，就可以適用轉換過後的新授權方式來讓人使用。舉前例來說、程式 A 到第 1.0 版為止都是採用 GPL 第 2 版（GPL2）來授權 ，經修改之後 A 專案可以特別標注為第 1.1 版，此時若是 1.1 版的修改者本身就是 A 專案的著作權利人，或是得到 A 專案原著作權利人的同意，那就可以將新版本號的 1.1 版改用 GPL2 以外的條款來授權散布，例如改採 LGPL2 或是 BSD 類別的授權條款，或者是乾脆將新版本號轉為採用 GPL2 與商業條款並行的雙重授權模式（dual-licensing model）也可以（註一）。並且、A 專案在 1.0 版與 1.1 版之間的差異可大可小，有時甚至兩個版本號的程式碼完全相同亦沒有問題，因為此種作法的重點就是在於讓使用者清楚辨識同一個自由軟體專案的不同版本號，並明白了解該專案不同的版本號就代表了「不同的授權方式」，從而日後運用上不會產生授權混淆的錯誤。
【利用新版本號釋出專案程式碼的實益】
透過「新版釋出、授權更改」方式，已經釋出的自由軟體專案程式碼，就可以事後完成授權轉換，但運作此種方式最重要的前提要件就是，新授權方式的轉換者本身必須是該專案全部程式碼的合法權利人，或至少已經得到權利人明示允許對此專案進行授權轉換，因為這種方式實質上其實是讓 1.0 版與 1.1 版新舊版本同時散布的「雙重授權模式」，願意以原授權方式得到程式原始碼的使用者，可以持續以舊授權模式利用該專案的 1.0 版，而接受新授權方式的使用者，也可以改用新的授權模式使用 A 專案最新的 1.1 版本。當然、此時很多自由軟體專案的開發者就會問，以「新版釋出、授權更改」的方式進行專案授權方式的轉換究竟有何實益？因為形式上似乎只是平行增加了 A 專案的授權方式，而若是使用者堅持延用舊的授權方式來使用該專案的程式碼，似乎也並沒有有效辦法能誘導使用者改用新的授權方式來使用這個專案？其實不然、前面雖然提到 1.0 版本的程式碼可以與轉換過授權的 1.1 版本完全相同，但實務上的狀況是，該 A 專案的權利人多會擴充或刪減該程式的功能後，再以 1.1 版本的方式釋出，在這種狀況之下，這些新編寫進來的最新功能，使用者就只能透過 1.1 版本的新授權方式才能取得，所以雖然 1.0 版本的授權方式並沒有辦法被權利人事後撤銷，但隨著 A 專案不斷的被增裨與改寫，多數使用者都會接受以新版本號的授權方式來使用該專案後續完成的程式碼，實質上來說、這就是一種自然演繹的引導方式。
【利用新版本號變更條款文字的實例】
其實、以版本號的變更來宣告授權內容的變更，在自由軟體授權領域裡幾乎已形成群體共識。舉 GNU 計畫另一款重要的授權條款 LGPL 為例，許多人都知道就版本別來看，LGPL 近年有 LGPL2、LGPL2.1 與 LGPL3 三個版本，但是大概很少人知道 LGPL 第 2 版的內容與 2.1 版的內容幾近完全相同，不同之處僅在於條款全名有所更改，並稍微調整了一些介係詞與相關的技術名詞（註二）。既然新舊版本的差異那麼的小，那麼為何世上會有文字內容幾近完全相同的 LGPL2 與 LGPL 2.1 版本的授權條款呢？其實這個條款版本號的修改，是 GNU 計畫的創立人 Richard Stallman 為了要將 LGPL 條款的全名，由最初的 "GNU Library General Public License"，改寫為 "GNU Lesser General Public License"，因為 LGPL 最初的全名 "GNU Library General Public License"，會讓許多的程式開發者誤以為只要是函式庫程式就只能採用 LGPL 來授權，而不能採用 GPL 這種更為開放的授權方式，對於 Richard Stallman 來說，這與他初始撰立 LGPL 的預期有所衝突（註三），所以為了將授權條款名稱裡的 "Library" 改為 "Lesser"，這世上就多了與 LGPL2 條款內容幾近完全相同的 LGPL 2.1，這就是一個透過版本號的變異來宣告授權文字有所變化的實例，從這個例子我們可以看到，實務上自由軟體授權條款內容變異時的嚴縝性，以及版本號在自由軟體授權領域裡的靈活運用。
【以 Qt 為實例進行授權轉換的說明】
「新版釋出、授權更改」的實例不在少數，目前因併購而歸屬於 Nokia 旗下的 Qt 就是一個相當著名的例子。Qt 是一個跨平台的圖形界面開發工具，最早由一家挪威公司 Trolltech 所開發並擁有著作權利，初期 Trolltech 透過自行撰寫的 Q Public License（QPL）與商業條款來雙重授權這個專案。不過因為 QPL 與 GPL2 在授權上並不相容，但自由軟體領域裡以 GPL2 授權的元件卻愈來愈多，所以為了調和 Qt 與這些 GPL2 授權元件的相容性，2005 年在發布 Qt 第 4 版（Qt/Windows 4）的時候，Trolltech 捨棄 QPL 改採 GPL2，自此以後 Qt 改為 GPL2／商業條款併行的雙重授權模式，後來隨著 2007 年 GPL3 定稿的發布，Qt 也透過程式改版的動作，將新版本號的 Qt 改為 GPL3／商業條款併行授權。不過這樣的 GPL3／商業雙重授權模式維持不久，因為之後 Nokia 公司收購了 Trolltech，並在 2009 年釋出 Qt 第 4.5 版時，加入了 LGPL2.1 授權條款為另一個使用者可選擇的授權模式（註四），自此 Qt 的授權狀態變為 GPL3／LGPL2.1／商業三重授權模式（註五）。回顧過去十年，Qt 所適用的自由軟體授權條款一變再變，不過這些改變都是在程式改版升級的時候加以進行，並且僅僅適用於新版與未來版本，過去已經發布的舊版 Qt 軟體，在授權內容上不會有任何的改變，這是一個「新版釋出、授權更改」的鮮活實例，同時、也是一個不因授權轉換而影響前版軟體授權狀態的最佳例證。
【跳脫傳統框架以建立長久良性的授權模式】
自由軟體所採用的是一種不同於傳統的授權模式，若是不多做論理直接採用既有的法律架構來處理相關問題的話，將有可能產生悖離現實運作的結論，進而引發許多難以解決的棘手問題。而在面對自由軟體專案授權方式轉換這一個問題的時候，鑑於目前並沒有相關的司法判決，因此自由軟體的授權特性與軟體社群的運作習慣，就顯得格外的具有參考重要性。如同之前所評論的，自由軟體授權條款具有授權給公眾利用後不間斷散布的特性，再加上經過十多年的實務運作，全球絕大多數的軟體使用者已經對於自由軟體的授權模式，產生不會向後撤銷的信賴共識，因此筆者透過此篇文章分享這個議題的論理觀點：自由軟體專案的授權態樣原則上不可嗣後撤銷，否則將會造成難以解決的全球性軟體授權混亂，而若是已釋出的自由軟體專案想要改變授權方式的話，則可以採用「新版釋出、授權更改」的方式，透過最新版本號的軟體釋出，逐步地改變專案程式碼在未來的授權方式。而也唯有在這樣的運作機制之下，全球的軟體開發者可以在互信互助的基礎下，共同維持良性的自由軟體開發循環模式，讓已經在全球發展近二十多年的自由軟體共同開發制度，繼續穩定而長久地運作下去。
註一：雙重模式的說明可以參見：林誠夏，自由軟體的商業應用模式（下）－雙重授權篇，自由軟體鑄造場電子報第 83 期，http://www.openfoundry.org/tw/legal-article-/1056-2010-07-15-10-36-02；林誠夏，20070130-Dual license-雙重授權模式的美麗與哀愁，http://lucien.cc/?p=62。
註二：LGPL 第 2 與 2.1 版的英文全文請參見：http://www.gnu.org/licenses/old-licenses/old-licenses.html#LGPL。
註三：從 Richard Stallman 的角度出發，他希望世上所有的軟體專案都能夠以 GPL 授權條款釋出散布，但因為函式庫的程式多以連結的方式供其他程式讀取資訊，若是全以 GPL 的方式釋出的話，那授權拘束性的涵攝範圍就會非常的大，這會導致許多自由軟體專案的程式開發者怯步而避免使用 GPL 來釋出其專案，所以退而求其次的提供授權拘束性範圍較窄的 LGPL 來讓這些專案開發者選用，但仍然期盼認同其理念的專案開發者，能適時的以 GPL 授權條款來釋出其所撰寫的函式庫程式。
註四：在 Nokia 公佈這項消息的新聞稿中，第三段第一句的文字就明確表示，Qt 不但繼續提供商業授權版本，所有過去版本的授權狀態也不會有任何的改變，該段原文："Qt 4.5 will also be available under commercial licensing terms, while licensing for previous versions of Qt remains unchanged."，新聞稿的原文連結請參照：http://qt.nokia.com/about/news/lgpl-license-option-added-to-qt。
註五：Qt 官網：http://qt.nokia.com/。QPL 英文全文內容請見：http://www.opensource.org/licenses/qtpl.php/。Qt 過往的授權歷史複雜，本文僅擷取重點加以說明，進一步資訊可以參見：http://en.wikipedia.org/wiki/Qt_(framework)#History。目前三重授權的介紹與分析可以參考：http://blog.linux.org.tw/~jserv/archives/002085.html。
[OSSF專欄] GPL 的授權規則與技術工程遵循之道–講者 Harald Welte 與 Armijn Hemel 會後專訪
林誠夏、林懿萱/採訪
自由軟體鑄造場於 2010 年 12 月 2 日所舉辦「自由軟體授權應用及商業建議二十講系列」第四講的活動已經圓滿落幕。此次活動邀請了 gpl-violations.org 組織的兩位核心成員 Harald Welte 以及 Armijn Hemel，針對商業運用 GPL 授權元件的義務性規定及產品授權狀態的查核進行說明與演示，演講內容的全程錄影與簡報可透過右列連結頁面取得：http://www.openfoundry.org/tw/workshop/details/115-the-rule-of-the-GPL-and-Its-compliance-engineering （註一）。而在會後、鑄造場更針對兩位講者的演講內容與開發背景，擬具了幾個幫助國人深化了解 GPL 授權議題的採訪問題，以下即為會後專訪內容的濃縮節本。
問題 1：請問您是什麼時候開始您的第一個自由軟體專案？而到目前為止，參與自由軟體專案開發的過程裡，最讓您難忘的經驗又是什麼？
Harald Welte：這其實是一個蠻難簡單回覆的問題，基本上呢，一開始就是下載了某些自由軟體的元件來用，然後也因為自己的需求而提報了某些功能（Feature）到程式的開發論壇，慢慢的算是參與了這些專案的開發，真的要說在程式寫作方面有所貢獻，應該是一個郵件伺服器（Mail Server）的相關專案，時間上的話，統括就是開始於青少年時代，那麼關於難忘的回憶，想到的是加入 iptables 專案的程式寫作，這帶給我密集式開發專案的相關經驗。
Armijn Hemel：沒錯、這是一個不好回答的問題，事實上我認為自己在自由軟體專案開發方面的參與程度不像 Harald 那麼多，雖然一直有在參與，但很難具體界定是集中參與哪一個專案，目前已經釋出的 Binary Analysis Tool（註二）算是一個我完整參與的開放原始碼專案。
問題 2：現在產業界很多公司，有時會因為時程壓力而選用自由軟體授權元件來進行產品開發，然後在後續散布上，卻沒有完全遵照這些自由軟體元件的授權規則，其中一部份的原因，也許是部份的軟體開發工程師認為這樣的行為日後不會曝光，或者說、存著僥倖的心理認為曝光後可能也無大礙，面對這些狀況，您認為元件的權利人提出相關的民事或刑事訴訟，會是最好的解決方式嗎？而若是有這樣的爭議案例發生在歐洲之外，您有評估過跨國提起訴訟的可能性嗎？
Harald Welte：當然、如果覺得侵權的事態嚴重，是有想過直接到產品生產國提出訴訟的想法。然而、查緝自由軟體專案的侵權事件其實也並非我們每天執行的業務，原則上、我們目前還是針對販售到歐洲的侵權產品來進行處理。而關於訴訟是不是最好的解決方式，嗯…應該這麼說，交通規則就是在那邊，比方說超速照相，超速照相攝影機的設置目的，不是要照到每一個超速行車的駕駛，但如果世上完全沒有超速照相攝影這個機制，那許多人就會毫無顧慮的超速駕駛，而導致交通狀況愈來愈差，所以必要的查緝與舉報對於自由軟體的侵權利用狀況而言，是不得不然的回應。
Armijn Hemel：我認為事情不一定非得從壞處（Bad side）來著眼，其實我們鼓勵商業公司盡量的利用自由軟體授權的元件來進行產品開發，因為這樣才是符合自由軟體元件重覆使用（Reuse）與持續改寫改進（Rewrite）的道理。然而、必須要特別強調的是，自由軟體授權元件的利用循環不應該是一條單向輸送的單行道（One way road），當你可以自由地下載、取得這些程式原始碼來加速產品開發的同時，不要忘了也要適當地釋出你所改寫的程式原始碼給收受後續版本的使用者，這樣才能進入自由軟體程式開發「取予和諧（Taking and giving）」的良性循環。
問題 3：自由軟體鑄造場定期會應國內企業的邀請，至各公司內部進行自由軟體授權議題的說明演說，而這些演說的內容又多以 GPL 授權條款的相關義務性規定為核心議題。從您的觀點來看，這樣的演說活動會有助於產業界加深對於自由軟體授權規則的了解，並協助他們遵循相關的授權規定嗎？
Harald Welte：當然、這樣的作為對於提升商業公司對自由軟體授權條款的了解必然是有所幫助的。但另一個問題就是，在場與講者互動的會是哪一類性質的參與者？因為很多軟體工程師在產業體制裡並不具有決策高度，就我們的經驗來說，如果對於某項產品的授權狀況有所疑問，也許要找到該項產品的產品經理才是一個適合對話的人選，產品經理對於產品的銷售方針、佈局，以及後續維護具有比較高的掌握權能，也就是說、對話應該要找到適合對話的對象。
問題 4：如果某個軟體專案的權利人並不是使用雙重授權（Dual-licensing model，註三）的方式來釋出他的專案程式碼，而單單僅用 GPL 的授權方式來散布這個軟體，當有使用者不遵守 GPL 的規定而侵權利用這些程式碼時，您認為權利人提出民事訴訟並獲得適當賠償金的機率高嗎？
Harald Welte：我想這個問題不大，如果確實有侵權利用的行為存在，而權利人又可以適當的證明這點的話。
Armijn Hemel：似乎在一些英美法系國家的法律會比較要求損失金額的證明，之前在歐洲自由軟體法律論壇（The European Legal Network，註四）裡也有過類似的討論串，但無論如何我們並不是執業的律師，而是自由軟體專案的軟體工程師，所以這個問題的答案我們持樂觀態度，但沒有辦法給太過深入的評論意見。
問題 5：在 Harald 的簡報中提到：「從 GPL 的授權理念出發，若是商業使用 Linux 與其他自由軟體的元件，但卻不容許社群參與者協同研究修改這些程式，某種程度也算是一種惡意的規避行為。」但是一般的狀況下，商業公司多會傾向先關心自身的產品利益，而不會將自由軟體授權條款的義務性規定放在第一優先的順位，如果這樣的狀況一再發生，從您的觀點來看，我們該如何媒合產業界與自由軟體開發社群走向互信互諒之途，而不是彼此敵視呢？
Harald Welte：我想有一個很重要的前提就是，產業界應該放寬自我的視野，而不是僅僅爭逐被傳統觀點侷限的所得利益，因為那樣會讓自身淪於短視（Short sighted）而忽視了公司可以得到的更大利益。如果產業界能了解善用自由軟體元件來加速產品開發所帶來的好處，則提供產品原始碼的要求與公司本身的利益就不會是零與一的競合。並且，公司的決策團隊也應該要正視自由軟體商業應用的相關發展，實務上我們常常接觸到許多商業公司的軟體工程師，他們本身對於自由軟體授權規則並非一無所知，而且也很樂意協助我們將產品不當利用 GPL 程式碼的狀況回報到上級單位，但往往回報之後的狀況是管理階層全無回應，這是一個最糟的狀況。所以關於建立產業與軟體社群之間順暢的合作關係，我會建議產業公司應該要有專責的部門來處理自由軟體授權的相關議題，這樣不但有助於提升產業公司本身的商譽與公共關係，也可以有效的導入社群的開發能量與群體創意。
問題 6：其實有不少今天的與會朋友，私下詢問我們這個問題，那就是像兩位這樣的自由軟體專案開發者，通常是怎麼賺取支應生活開銷所需的相關費用呢？
Harald Welte：諮詢費用對於自由軟體開發社群成員而言，是可能產生收益的項目之一，現在世面上不乏善用自由軟體授權元件來加速產品開發的產業公司，而如果你對自由軟體授權元件的開發知識與運用技術擁有較高的掌握程度，就可以協助這些產業公司調校、改寫相關元件的功能，讓產品的開發時程能更有效率的縮短，以在市場上獲取更大的收益。
Armijn Hemel：我想重點之一是先讓別人認識到你的軟體開發能力，讓他們對你所能提供的技術產生興趣，這樣就可以產生後續協同開發的合作關係。
問題 7：兩位有其他建議或是評論想透過這篇專訪來向自由軟體鑄造場電子報的讀者傳達嗎？這個傳達的對象可以是臺灣的產業公司，也可以是在地的自由軟體開發社群。
Harald Welte：我想最後要補充說明的就是，自由軟體的運用和開發不僅僅只是一種開發方式的改變而已，GPL 授權有它背後存在的開放理念，如果不能了解這些理念，產業界將很難順暢地與軟體社群之間有協同合作的關係，而若是當產業界開始了解這樣的開放理念後，他們會發現自由軟體的開發循環，將確實可以為產業的收益帶來相當程度的增裨與好處。
註一：自由軟體鑄造場會將二十講系列的活動花絮、影片以及講師簡報放置於 OpenFoundry 上該活動的報名網頁上面，供需要的使用者自行下載觀看，前三講的下載網址分別為：
1、2009.11.14 http://www.openfoundry.org/tw/workshop/details/58--1。
2、2009.11.28 http://www.openfoundry.org/tw/workshop/details/59--2 。
3、2010.05.11 http://www.openfoundry.org/tw/workshop/details/84 。
註二：Binary Analysis Tool 是一套檢測專案程式碼授權狀態的軟體程式，採用 Apache License 2.0 的方式對外釋出，任何人皆可依 Apache License 2.0 自由地下載、安裝，並後續修改這個程式，其專案首頁連結如右所列：http://www.binaryanalysis.org/。
註三：在自由軟體授權領域裡，雙重授權模式這樣的用語通常意指「權利人同時將專案的程式碼以商業授權與自由軟體授權二種授權方式併行散布」，使用者如果想要得到商業授權的版本，可以直接向該權利人洽談商業授權的使用條件與費用，但同時亦可以下載免徵授權金的自由軟體版本來使用，但如果是以自由軟體授權方式取得這些程式碼，後續再修改散布該程式時，就需要受到該自由軟體授權條款的拘束。而以雙重授權方式釋出的軟體專案，在發現侵權利用的行為時，因為此專案本身早已律定了商業授權模式的收費標準，此時就能轉而利用商業授權的收費標準來舉證損失金額，於是乎在司法爭訟上，往往具有要求較高賠償金數額的求償地位。
註四：歐洲自由軟體法律論壇是由歐洲自由軟體基金會（Free Software Foundation Europe）所設立並營運的法律論壇，其匯集並傳達自由軟體授權運用方面的各項知識，並透過反覆討論的方式以凝聚參與者的共識，其網頁連結如右所示：http://www.fsfe.org/projects/ftf/network.en.html。
[技術專欄] 以 scanlogd 偵測埠掃描事件
老薯條(http://vulscan.wynetech.com.tw)/文
前言
所有犯罪行為通常具有一定的行為模式，即確立目標 → 勘察環境 → 決定適當的工具 → 攻擊。網路攻擊也不例外，當駭客決定目標後，即會以掃描工具來針對目標進行掃描，而後再根據掃描結果決定攻擊方式來進行攻擊。因此，如果能儘早得知進行掃描的惡意來源 IP，即可在惡意攻擊者進行攻擊之前來進行防堵，進而降低系統的危害，在本文中，筆者將介紹一套掃描偵測工具（scanlogd，官方網站為：http://www.openwall.com/scanlogd/），用來偵測實施惡意連接埠掃描的來源 IP，以便管理者能提早因應相關情況的發生。作業系統掃描原理
在駭客決定攻擊目標後，第一個步驟往往是先行探測目標主機的作業系統。由於每一家作業系統對於封包的處理方式均不同，探測軟體即可利用此種特性來辨識出不同的作業系統。由於此種方式就像人類的指紋一樣，所以又稱為「作業系統指紋 (OS Fingerprint)」辨識，作業系統探測方式可分為主動式及被動式，如下所述：主動式：
探測軟體透過傳送特別打造的 TCP，UPD 或 ICMP 封包至被探測主機端，再根據被探測主機回傳的封包特徵，來辨識出該主機的作業系統。此種工具以 nmap 為代表。官方網址為：http://nmap.org/。被動式：
探測軟體並不主動傳送封包至被探測主機上，而是被動的監看往來封包，籍由往來封包的特徵來辨識出作業系統，此種探測軟體以 p0f 為代表。官方網址為 http://lcamtuf.coredump.cx/p0f.shtml。在本文中將不多加探討此種探測技術，請有興趣的讀者自行參閱相關說明。接下來，我們繼續說明主動式作業系統的辨識原理：
- FIN 封包探測或 XMAS 封包探測
- Bogus（偽造）封包探測
- 以 Tcp initial window（tcp 初始化視窗）探測
- ICMP TOS (Type Of Service) 判別
路的連線狀態與連線的正確性。常用的 ICMP 類型說明如下表：
| Icmp類型 | 說明 |
| 0 | Echo Reply (代表一個回應信息) |
| 3 | Distination Unreachable (表示目的地不可到達) |
| 4 | Source Quench (當 router 的負載過高時，此類別碼可用來讓發送端停止發送訊息) |
| 5 | Redirect (用來重新導向路由路徑的資訊) |
| 8 | Echo Request (請求回應訊息)，我們一般使用ping指令確認對方主機是否有回應，即使用此類型送出Request要求。如 果對方存在，即會回應類型０的Echo Reply封包。 |
| 11 | Time Exceeded for a Datagram (當資料封包在某些路由傳送 的現象中造成逾時狀態，此類別碼可告知來源該封包已被 忽略的訊息) |
| 12 | Parameter Problem on a Datagram (當一個 ICMP 封包重複之前的錯誤時，會回覆來源主機關於參數錯誤的訊息) |
| 13 | Timestamp Request (要求對方送出時間訊息，用以計算路由時間的差異，以滿足同步性協定的要求) |
| 14 | Timestamp Replay (此訊息純粹是回應 Timestamp Request 用的) |
| 15 | Information Request (在 RARP 協定應用之前，此訊息是用來在開機時取得網路信息) |
| 16 | Information Reply (用以回應 Infromation Request 訊息) |
| 17 | Address Mask Request (這訊息是用來查詢子網路 mask 設定信息) |
| 18 | Address Mask Reply (回應子網路 mask 查詢訊息的) |
ICMP 封包除了可用來確認主機的狀態外，也可利用探測作業系統的種類，探測程式可利用 ping 程式送出一個 icmp echo 的請求至要探測的主機上，再由對方主機回的 echo reply 封包中的 TTL (Time To Live) 的欄位值（不同作業系統對於 TTL 欄位值的設定都不一樣）來初步判斷主機的作業系統。有興趣的讀者可利用 ping 指令來觀察 linux 系統及 windows 系統回傳封包的 TTL 欄位，如下所示：
ping 來測試其回應值，即可發現兩種作業系統所回應封包中的 TTL 值明顯不同。掃描軟體即可利用此種特徵來初步區分作業系統的種類，如下圖為 linux 系統及 windows 系統的測試畫面：
▲圖1
▲圖2
由上可明顯的看出不同的作業系統會設定不同的 TTL 值，探測軟體即可利用此種特性來初步判別作業系統的種類。
另外一種探測方式是利用管理者不當的設定系統組態而造成作業系統資訊外洩，讀者可利用如 telnet 即可能獲知作業系統的資訊。如下圖即可得知該主機的作業系統：
▲圖3
另外讀者也可利用現成的工具來探測主機的作業系統，如使用 nmap – O 來偵測主機的作業系統，如下圖所示：
▲圖4
埠掃描 (port scan) 原理
在確定主機的作業系統後，接下來的步驟即為確認該主機上運作的服務資訊以便擬定攻擊策略。主機服務的偵測主要是利用被探測主機對於探測封包的回應情況，來判別被探測主機的連接埠 (Port) 是否為開啟的情況。所使用的探測技術，如下所述：
全連接技術
此為正常連接的探測方式，利用與被探測主機完成三向交握 (Three Handshake) 來確認被探測主機的埠是否處於開啟的狀態。三向交握原理如下所述：
▲圖5
在上圖中，來源端欲與目的端完成連線，會經由下列步驟來完成連線：
1.來源端主機送出 SYN 封包至目的端主機來要求連線。
2.目的端主機收到 SYN 封包要求 後，會回覆 SYN＋ACK 封包給來源端主機。
3.來源端主機收到目的端主機回覆的 SYN＋ACK 封包後，即會回覆 ACK 封包至目的端主機，至此完成三向交握 (Three Handshake) 流程，雙方建立連線。
一旦掃描軟體被探測主機順利完成三向交握 (Three Handshake) 並與目標主機完成連線，即可代表該探測埠處於開啟的狀態。反之即代表探測埠處於關閉的狀態。此種掃描方式即稱為全連接掃描。全連接掃描由於已完成正常的連線，所以此種掃描會被防火牆或 IDS（入侵偵測系統）所記錄。
半連接探測技術
由於使用全連接方式的掃描，很容易即被被防火牆或 IDS（入侵偵測系統）所記錄，所以一般的埠探測技術大都不會與被探測主機完成正常的連線以避免被記錄，此種的探測技術稱為半連接探測技術，常用的半連接探測技術，敍述如下：- SYN 封包掃描
- SYN/ACK 封包掃描技術
- FIN 封包掃描技術
nmap -sS #利用 syn 掃描來探測被探測主機所開啟埠資訊
如下圖示:
▲圖6
安裝 scanlogd
請讀者依下列步驟，安裝 scanlogd：
1.請至官方網站取得最新版本的 scanlogd（筆者所取得的版本為 2.2.6）
2.adduser scanlogd #新增一個 scanlogd 的使用者
3.解壓縮後，即使用 make linux 來編譯 scanlogd
編譯成功後，執行 scanlogd 即會常駐在系統中。
此時，請讀者在另一台主機上，以 nmap 程式掃描 scanlogd 所在的主機上（如 nmap ），查閱 scanlogd 所在主機的 /var/log/messages，即可發現如下的掃描資訊（可清楚的得知進行埠掃描的惡意來源 IP）。
▲圖7
讀者可經常的查閱 /var/log/messages 來掌握進行埠掃描的惡意來源 IP 資訊。
[源碼秘技] 用 Android 手機充當電腦的無線鍵盤及滑鼠
線人/文
各位讀者也許不太明白：「我的電腦已經配備鍵盤及滑鼠，為什麼還要用智慧型手機來充當無線鍵盤及滑鼠呢？」筆者相信，RemoteDroid 這個軟體的出現，最大的受惠者其實是筆記型電腦的使用者。有用過這一類電腦的使用者都會同意它預設的觸控板位於鍵盤的下方，實在太不順手了，因此他們往往會使用 USB 滑鼠連接筆記型電腦，讓操作電腦更為方便。如果這一類使用者同時也有一台 Android 智慧型手機，則大可下載及安裝 RemoteDroid，將手機變成「無線觸控板」並放在筆記型電腦的右邊，這樣使用者便不用再攜帶另一支 USB 滑鼠了。再者，近期推出的 Android 智慧型手機，不少都強調大螢幕，這種手機就更適合充當電腦的觸控板了。
除了可模擬電腦的觸控板外，RemoteDroid 亦可同時模擬電腦的鍵盤，這樣使用者便可透過手機的實體鍵盤或虛擬鍵盤，在電腦上輸入文字。不過這個功能方便與否，要看使用者的手機是否設有實體鍵盤。筆者始終認為透過智慧型手機螢幕上的虛擬鍵盤輸入文字，總是比不上實體鍵盤來得方便。
軟體名稱：RemoteDroid
最新版本：1.4
軟體授權：GNU General Public License (GPLv3)
系統支援：Android
官方網站：http://code.google.com/p/remotedroid/
各位使用者可透過 RemoteDroid 的官方網站免費下載這個軟體。這個軟體分為兩部份：安裝於 Android 手機的 APK 檔案，以及安裝於電腦的伺服器軟體。前者是一個 APK 檔案，以「.apk」為副檔名，透過 Android 手機中的檔案總管開啟 APK 檔案，便可選擇將軟體安裝至 Android 手機。不過，事前使用者要確定 Android 手機的【設定】中的【應用程式】介面，當中「未知的來源」的核取方塊已勾選。後者則是一個名為「RemoteDroidServer」的 ZIP 壓縮檔，將這個 ZIP 檔案打開後，便會發現有一個檔名「RemoteDroidServer.jar」的檔案，那是一個 Java 程式，理論上可於任何支援 Java 的作業系統上執行，包括 Windows、Mac OS X 及 GNU/Linux 系統。以下筆者以 Mac 電腦作示範。
在正式使用 RemoteDroid 時，首先先啟動智慧型手機的 Wi-Fi 功能。要使用這個軟體，智慧型手機與電腦須連接同一個 Wi-Fi 網絡。
▲圖1
然後，便可執行安裝於手機裡的 RemoteDroid 軟體。
▲圖2
執行 RemoteDroid 軟體後，會見到如下圖的畫面。
▲圖3
這時候，使用者便可按照上述畫面的指示，執行儲存於電腦裡的「RemoteDroidServer.jar」程式。如無意外，電腦會出現這個視窗。
▲圖4
視窗中會出現一個 IP 位址，就在「Your IP address is:」字句之後。此時使用者便可在手機中的 RemoteDroid 畫面中「Enter your IP address below:」下的欄位，輸入電腦顯示的 IP 位址。
▲圖5
再點選〔Connect〕。如無意外，手機會顯示如圖的畫面。
▲圖6
這就是 RemoteDroid 模擬電腦觸控板的操作介面了。為了方便操作，使用者更可將手機以橫向的方式擺放，令 RemoteDroid 的操作介面切換為橫向式。
▲圖7
RemoteDroid 操作介面下方的左、右長方格分別模擬電腦的滑鼠左鍵及右鍵。在手機螢幕上點擊這兩個長方格，便等同於在電腦滑鼠上按左鍵及右鍵。
▲圖8
▲圖9
此外，智慧型手機的導航鍵亦可充當電腦的方向鍵，手機導航鍵可模擬為電腦的〔CTRL〕鍵，而手機的〔MENU〕鍵則可模擬為電腦的〔ESC〕鍵。
如果使用者所用的智慧型手機不設實體鍵盤，RemoteDroid 操作介面下方中間會出現〔鍵盤〕圖示，點選這個圖示則可啟動手機的虛擬鍵盤，之後使用者透過虛擬鍵盤所輸入的文字，都會在電腦上重現。如果使用者所用的智慧型手機設有實體鍵盤，直接透過實體鍵盤打字便可。
▲圖10
最後，按下手機的〔返回〕鍵便會結束 RemoteDroid 的模擬模式，返回主畫面。下次使用者再次使用 RemoteDroid 的時候，便會發現主畫面中的「Recently Used Hosts」會列出曾經連接過的位址。
▲圖11
[源碼報報] Java 規格投票落敗 Apache 軟體基金會退出 JCP 執委會
謝良奇/編譯
Java Community Process (JCP) 在執行委員會投票表決下，通過了 Java 7 與 Java 8 的技術規格。Java 7 的 JSR-336 和 Java 8 的 JSR-337，同樣獲得 12 票贊成與 3 票反對。其中投下反對票之一的 Apache 軟體基金會 (Apache Software Foundation，ASF)，更在不久後宣佈退出 JCP 執行委員會。
新 Java 7 和 Java 8 釋出將包含新模組化與生產力改進等多項技術創新。儘管獲得多數執行委員會成員的支持，其中卻有若干爭議。最主要的一點正是來自 Apache 軟體基金會。Apache 軟體基金會關切的，並非 Java 7 與 8 的技術內容，而是 Oracle 對於新版 Java，究竟採用的授權為何。
投下反對票的 Google 和 Apache 軟體基金會表示，他們的決定和 Oracle 計畫的技術內容無關，而是要反對 Oracle 加諸的使用範圍和授權限制。Apache 軟體基金會成員 Geir Magnusson Jr. 表示，這些 JSR 與 Oracle 提供的授權相衝突。Java 7 和 8 技術相容性套件 (Technology Compatibility Kit，TCK) 的授權排除了著眼於嵌入式系統的實作者。
Apache 關注的另一項議題是 TCK 中阻礙獨立實作進行散佈的限制。來自 Apache 軟體基金會的 Apache Harmony 專案正是此一問題的焦點。Oracle 在毫無解釋的情況下，拒絕給予 Harmony 使用 TCK 的授權。意味著 Apache 軟體基金會無法讓 Harmony 此一獨立的 Java SE 實作，進行官方標準的相容性測試。
Google 的 Android 行動作業系統在其 Dalvik Java 虛擬機器中，使用了部份的 Harmony。Oracle 宣稱 Android 侵害 Java 專利而正對 Google 提出控告。
事實上，這不是 Apache 首次對 TCK 授權感到不滿。有關 TCK 授權條款的爭議，要回溯到 Sun 身上。當 Sun 在 2007 年將其大部分 Java 技術以開放源碼的 GPL 重新授權時，卻在 Java 的相容性測試套件上維持使用私有授權。
Java 規格中包含了爭議的使用範圍條款，要求所有 Java 實作都必須通過 TCK 的測試。反對人士認為這不僅有違開放源碼的精神，更抵觸了所有參與 Java 發展各方所同意的協議內容。
Apache 軟體基金會過去 10 年一直是 JCP 執行委員會成員，同時也是許多重要且知名開放源碼 Java 專案的來源。該組織明白指出 Oracle 拒絕給予 Harmony 授權，已經不符合 JCP 的管理原則。Apache 軟體基金會並且在日前呼籲其他 JCP 成員投票反對 Java 7 和 8。
在 Apache 軟體基金會下達的最後通牒中，該組織向 Oracle 表示，一旦他們作為 Java 規格時作者的權利，沒有獲得 JCP 執行委員會在其能力範圍內的支持，該組織將會終止與 JCP 的關係。該基金會總裁 Jim Jagielski 曾表示，假如在 Java 7 投票上落敗，該組織將會為了是否為自由使用與授權限制持續奮戰，而面臨艱難決定。
Java 7 與 8 投票表決結果公佈後不久，Apache 軟體基金會果真宣佈退出 JCP 執行委員會。Apache 軟體基金會在聲明中表示，近日的 Java SE 7 投票是 JCP 執行委員會展示，該會有意捍衛 JCP 作為開放規格程序的最後機會。
該基金會表示，他們做出 JCP 並非開放規格程序的結論，而 Java 規格則是一項必須依照規格領導者所挑選的條款，直接從規格領導者取得授權的私有技術。而 Oracle 此一個別實體的商業考量，將持續嚴重地干涉並影響該產業生態圈的透明化管理。
Apache 能讓 Oracle 於最後關頭放行 Harmony ，成為標準 Java 的唯一機會，是盡力爭取 IBM－Apache 和 Harmony 的長期支持者－成為同一陣線。然而，當 Oracle 日前拉攏 IBM 支持 OpenJDK 這套開放源碼 Java SE 後，Apache 退出 JCP 顯然已成了不得不下的一個決定。
如今看來 Java 恐怕將走向分支一途，一方面有 OpenJDK 這套官方的開放源碼 Java，另一方面有 Apache 的 Harmony。外界認為用不了多久，Oracle 也會對 Apache 做出法律行動。最後，或許法庭將會決定，當一切全都由一家公司說了算，這樣的開放源碼專案究竟還有幾分開放可言。
相關網址：
1.Java 7 和 8 在 Apache 反對中通過
http://www.devx.com/architect/Article/46123
2.Apache 在 Java 決勝投票中輸給 Oracle
http://www.theregister.co.uk/2010/12/07/apache_google_vote_no_oracle_roadmap/
3.Apache 基金會退出私有 Java 程序
http://www.zdnetasia.com/apache-foundation-quits-proprietary-java-process-62205130.htm
4.Apache 被迫創建 Java 分支
http://www.zdnet.com/blog/open-source/apache-is-being-forced-into-a-java-fork/7945
5.Apache 退出 JCP 執行委員會
http://www.h-online.com/open/news/item/Apache-resigns-from-the-JCP-Executive-Committee-1151054.html
[源碼報報] PrimeSense 釋出微軟 Kinect 官方開放源碼驅動程式
謝良奇/編譯
負責微軟 Kinect 之中 3D 技術的研發公司 PrimeSense，與 Willow Garage 和 Side-Kick 共同釋出 Kinect 的 Windows 和 Linux 開放源碼驅動程式。此驅動程式來自若干獨立程式開發者的成果，如今獲得廠商的認可。而微軟似乎也因為意識到業餘開發者在創新 Kinect 姿勢控制應用上的潛力，開始主動提供支援。
微軟的 Kinect 硬體裝置是該公司 Xbox 360 遊戲主機的動作感知周邊。Adafruit Industries 的團隊之前曾公開提供獎金給最先開發出 Kinect 開放源碼驅動程式的個人或團隊。獎金最初為 1000 美元，隨著微軟當時向媒體表示不會容忍對其產品的修改行為後，增加到 2000 美元，後來更提高到 3000 美元。
當時獲得這筆獎金的是 Hector Martin 這名黑客。Martin 在其 Linux 筆電上開發出來的這套開放源碼驅動程式，支援了深度與 RGB 影像，並可在 OpenGL 視窗上顯示這些影像。Martin 本人並沒有 Xbox，他說這套驅動程式僅在實驗階段，但已證實其可行性。除了提供 3000 美元給 Martin 用以支付其合作團隊所需的黑客工具和設備外，Adafruit 也捐贈了 2000 美元給電子前哨基金會 (Electronic Frontier Foundation)，該基金會為一非營利的數位權利宣傳與法律組織。
PrimeSense 此次釋出的驅動程式提供對 Kinect 音訊、視訊、深度感測器的存取，並包含一組稱為 OpenNI 的 API。這組 API 可提供與 PrimeSense NITE Middleware 的接駁，允許在被拍攝的人體上疊蓋向量骨架 (vector skeleton)，達到即時的動作捕捉。此外，該驅動程式也包含了手勢辨識、語音指令以及場景分析器。該分析器可偵測前景中的人物，並將人物與背景分離。除了 Kinect 外，OpenNI 也支援其他的 PrimeSense 3D 攝影機。
原始程式碼、詳細說明文件、範例程式可自 OpenNI.org 下載。該廠商希望透過程式碼釋出，能帶動 3D 攝影機運用於動作偵測和姿勢控制的開放源碼發展。
相關網址：
1.Kinect 官方開放源碼驅動程式
http://www.h-online.com/open/news/item/Official-open-source-driver-for-Kinect-1152601.html
2.Kinect 官方開放源碼驅動程式釋出
http://kinecthacks.net/official-kinect-drivers/
[源碼報報] Netflix 暢談開放源碼應用
謝良奇/編譯
儘管開放源碼廣為應用於商業領域中，已是不爭的事實。對於開放源碼是否適任商業用途的疑問，多添幾個高知名度的成功應用例子，似乎也無傷大雅。除了像 Facebook、Twitter 等公司加入 Google、Amazon 行列之外，還有另一家知名企業 Netflix 也是開放源碼應用大戶。
Netflix 系統與電子商務工程副總裁 Kevin McEntee 在題為“我們為何使用並貢獻開放源碼軟體”的部落格文章中表示，他們在金錢、時間、人力、能量上的預算有限，因此必須將其技術開發工作，聚焦在清楚區隔 Netflix 且為其客戶創造歡樂的串流影片軟體上，這些限制使他們得依靠前人成果，這些成果解決了網際網路規模公司共同面臨的技術挑戰。
McEntree 指出，該公司使用部份商業軟體，不過通常有替代性的開放源碼軟體可資使用，特別是實作開放標準的開放源碼軟體。開放源碼軟體專案通常來自軟體開發者的自願性工作，這些開發者對於一次性解決方案重複地解決共通問題，感到厭煩，或者體認到他們可以提供比商業產品更為簡單而優雅的替代方案。
好的開放源碼專案很重要的一點，在於專案發展出自己的動力，並由良好的持續改進週期進行長時間的維護。McEntree 表示 Netflix 很早以前就加入了這股趨勢，並自積極演進的開放源碼專案上獲得相當大的利益。透過對專案的貢獻，他們也再次地受惠，因為社群會持續地改善 Netflix，進行修補和增添新功能。最終這些改善又會回到 Netflix。
McEntree 並列舉了該公司使用且貢獻的開放源碼專案，包括 Hudson、Hadoop、Hive、Honu、Apache、Tomcat、Ant、Ivy、Cassandra、HBase 等等。
由於 Netflix 和 Google、Facebook 等公司的顯著差異，該公司支持開放源碼的消息證實了開放源碼軟體適合各種不同層次用戶的能力。此外，該公司列舉使用和貢獻的開放源碼軟體清單，擴展了一般的 LAMP 堆疊，也證實了開放源碼軟體在商業應用上的廣泛程度。
儘管 Netflix 對開放源碼的應用獲得不少迴響，也傳出不同的聲音，認為該公司雖然受惠於開放源碼，但卻沒有讓其用戶享受到同樣的好處，也就是 Netflix 缺乏對 Linux 桌面的播放支援。
相關網址：
1.Netflix 暢談開放源碼
http://blogs.computerworlduk.com/open-enterprise/2010/12/netflix-opens-up-about-open-source/index.htm
2.誰在商業上使用 Linux 和開放源碼？
http://www.zdnet.com/blog/open-source/who-uses-linux-and-open-source-in-business/7951
3.Netflix 高談開放源碼，忘了 Linux
http://www.networkworld.com/community/node/69722
[源碼報報] Oracle 宣稱擁有 Hudson 商標權
謝良奇/編譯
Oracle 再次宣稱對開放源碼專案的所有權，這次的焦點是當初由 Sun Microsystems 所開發的 Hudson 專案，該專案為知名軟體建構與監控服務。此次爭議的導火線為未經警告封鎖 Hudson 用戶，加上長期以來不滿 Oracle 的 Java.net 專案網站架構，因此 Hudson 開發者已經在 GitHub 另覓新的落腳處。
Oracle 表示他們接受用戶將服務遷移到非 Oracle 所有的伺服器上，不過他們不能再使用 Hudson 名稱。Oracle 工具與中介軟體架構長資深副總裁 Ted Farrell 指出，Oracle 由於購併了 Sun，因而擁有 Hudson 商標。
Farrell 在 Hudson 郵件論壇上表示，因為這是開放源碼專案，該公司無法阻擋其他人創建 Hudson 分支。不過他們擁有該名稱的商標，因此其他人不能在核心社群之外使用該名稱。該名稱是由購併 Sun 所得來的。他說該公司喜愛 Hudson，希望見到該社群成長，
Oracle 對 Hudson 的主張，和日前 OpenOffice 社群決定自行管理該專案時，該公司針對 OpenOffice 名稱的態度如出一轍。該社群人士最後決定使用新的名稱 LibreOffice，並創建程式碼分支。
這次 Hudson 事件的導火線，是 Oracle 不久前未經警告就封鎖 Hudson 用戶。在 11 月 22 日早上，開發者發現無法存取原始碼倉儲以提交程式碼，而 Hudson 郵件論壇也被關閉。之所以無法存取服務是因為 Oracle 將 Hudson 的 Java.net 伺服器移轉到名為 Kenai 的新代管和協同合作平台。Kenai 同樣來自於 Sun。
被封鎖於 Hudson 外的，包括 Hudson 原始開發者 Kohsuke Kawaguchi，以及 Oracle 的主要 Hudson 維護者 Winston Prakash。雖然 Oracle 曾寄發一封電子郵件給 Kawaguchi，告知此一更動，但 Kawaguchi 並未收到該信件。
開發者在 11 月 30 日開始轉移 Hudson。鑑於 Google Groups 和 Nabble 的功能性與搜尋功能，該社群的郵件論壇存檔和即時郵件論壇被移轉到上述服務。程式碼則被轉移到 GitHub。這一套系統甚至在 Oracle 重新於 Java.net 開啟 Hudson 前，就已經開始運作。
Farrell 表示，Oracle 擁有 Hudson 名稱。他指出，對於 Hudson，與其他 Java 社群連接，並且利用他們即將在 Java.net 推出的嶄新功能，是相當重要的。留在 Java.net 跟搬移到 Git 並不相衝突，這並非移往 GitHub 的要求之一。他還說，留在 Java.net 可以確保來自全球最大 IT 組織之一的運行時間與可靠性。
從 Reddit 上的開發者回應看來，他們顯然沒有認真考慮 Oracle 的保證，而社群正在期待看到 Hudson 分支的創建。
由於購併 Sun，Oracle 將擁有 Hudson 的名稱，而名稱和認同有關。MySQL、OpenOffice、Hudson 都是開放源碼界舉足輕重的名號。然而，更大的問題在於，讓 Hudson 的程式碼和開發者離開，對 Oracle 將是一大損失。
根據 CloudBees 的資料，Hudson 是最普及的整合平台，有超過 2 萬 5000 家企業用戶和 290 位貢獻者。這些客戶才是 Oracle 想要的。該公司希望將這些企業連接到該公司的開發者與工具佈局上。儘管目前看不出 Oracle 對 Hudson 的計畫為何，有可能 Oracle 會將 Hudson 透過 Kenai 整合到旗下的 Java 整合開發環境 JDeveloper。
相關網址：
1.Oracle 宣稱擁有 Hudson 商標
http://www.theregister.co.uk/2010/12/01/oracle_owns_hudson/
2.不滿 Oracle：Hudson 另覓新屋
http://www.h-online.com/open/news/item/Unhappy-with-Oracle-Hudson-looks-for-a-new-home-1145734.html
[源碼報報] 天網誕生了嗎？美國空軍的超級電腦由 PS3 + Linux OS 組成
陳瑞霖/編譯
如果身邊的人想買 Microsoft Kinect，你也許該提醒他真實世界中的戰爭機器正在被 Sony PS3 模擬監控中，並且有可能演化成電影魔鬼終結者中，未來世界主宰一切，殺人不眨眼的「天網」伺服器。12 月 1 日美國空軍公佈了 1 台用 1760 台 Sony Playstation 3 Cell 處理器以及 168 顆 GPU（Graphics Processing Unit）晶片組成的超級電腦。
這項計畫已經悄悄進行超過一年的時間了，先前第 150 期電子報中曾講到美國空軍將採購 PS3 組成超級電腦（http://www.openfoundry.org/index.php?option=com_content&task=view&id=2351&Itemid=56;isletter=1），現在這個計畫已經研發完畢並且具有高度新聞性，因為在硬體配置方面，這是一台用遊戲主機組成的高效能軍用電腦。
這台超級軍用電腦叫作 Condor（禿鷹），一開始的建置目的是研究用途，功能特色為能負荷大量消耗運算資源的影像辨識軟體，所以可以進行高效能的影像叢集處理，並從繁雜的雷達及影像監視資料中，找出特定的人像或車輛影像，而這些優異的影像分析能力，也能夠對人工智慧方面的研究有所幫助。為了於其上運行易於客製化的開放源碼 Linux 作業系統，Condor 系統採用的是舊型的 PS3 主機（註一），執行的作業系統為修改版的 Fedora Linux 以及 Yellow Dog Enterprise Linux。Condor 擁有 500 Teraflops 的運算能力，整套系統的效能位居全世界超級電腦排行榜第 33 名。
根據建造 Condor 系統的 Air Force Research Laboratory 的說法，這套系統的研究與組裝共耗費 2 百萬美金，相當於同等效能機器客製化金額的 5％ ~ 10％，實驗室估計 Condor 的影像辨識軟體能夠叢集監視方圓 25 平方公尺以內的區域影像。而由於電視遊樂器擁有傑出的運算能力，近來一直有傳聞部份國家的軍事機構，有意將遊戲主機拿來當作戰爭武器的操作系統，2000 年時有新聞媒體報導，伊拉克獨裁者 Saddam Hussein 打算大量採購當時在美國賣到缺貨的 PS2，組裝成能夠控制飛彈發射系統的超級電腦，英國情報單位當時駁斥該則報導為沒有根據的謠言（註二），但是現在隨著美方的 Condor 現世，也許足以證明，歷年來的這一切相關報導，可能不會完全為空穴來風！
相關網址：
1.美國空軍啟用 2016 台 PS3 組成的超級電腦
http://www.itworld.com/government/129657/air-force-launches-supercomputer-made-2016-ps3s
2.美國空軍使用 PS3 組成超級電腦
http://www.gamasutra.com/view/news/31784/US_Air_Force_Creates_Powerful_Supercomputer_Out_Of_PS3s.php
3.美國空軍實驗室啟用 Condor 超級電腦
http://www.afmc.af.mil/news/story.asp?id=123232827
4.美國空軍仍舊使用 PS3 - 世界第 33 的超級電腦
http://www.tomshardware.com/news/usaf-supercomputer-ps3-playstation-cell,11727.html
註一：PS3 新的薄型主機不允許使用者自行安裝 Linux 作業系統，新聞報導請見右方連結：http://www.gamepro.com/article/news/214589/ps3-drops-linux-other-os-support/。
註二：當初首先報導的是 WorldNetDaily，但有相同多篇文章駁斥其推論的不合理處，詳情可見，流言追追追：電視遊戲史上十大流言背後的真相－海珊想要用 PS2 組成飛彈導航系統：http://www.crispygamer.com/classics/2010-01-28/mythbusters-the-truth-behind-10-great-videogame-myths.aspx；科技產品都市傳奇－海珊蒐集的 PS2：http://tech.uk.msn.com/features/photos.aspx?cp-documentid=149698608&page=3。
[OSSF新聞] 第一次的面對面接觸 - OpenFoundry 使用者聚會
OSSF工作團隊/文
2010 年 12月 22 日，自由軟體鑄造場工作團隊（Open Source Software Foundry, OSSF）首次嘗試舉辦了 OpenFoundry 使用者聚會，工作同仁是帶著既期待又擔心的心情，擔心的是活動當天的人數因為冬至而而不如預期，但也期待能夠透過此次活動，與 OpenFoundry 的使用者面對面接觸，以更加了解使用者的需求，並依此檢討改進網站所提供的相關服務。幸運的是，活動當天的參與人數比預計超出許多，而活動的進行也在參與者的熱情配合下，充滿了歡樂的氣氛。
▲ 圖一：OpenFoundry使用者聚會參加者的自我介紹
本次活動的參與者來自不同的領域，有些是社群成員、有些是大專院校的學生、有些是常來參加 OpenFoundry 技術分享工作坊的朋友們，當天大家介紹著自己所參與的組織與專精的開發領域，透過本次活動，我們認識了彼此。而雖然擴音設備不足這點略有瑕疵，但在與會者的包容與積極參與下，活動可以說是圓滿的落幕了。透過首次的 OpenFoundry 使用者聚會，我們得到了一些肯定，未來將持續努力提升平台的相關服務。往後，亦將定期舉辦 OpenFoundry 使用者聚會，依據使用者提供的寶貴意見進行反思與檢討，以讓 OSSF 團隊能將所提供的服務改正的更臻完善。
▲ 圖二：參與者與主持人問答時間，任何在場的參與者都可以發表自己對OpenFoundry 的批評與建議。
[社群花絮] Drupal 7.0 即將於 1 月 7 號舉行發行派對，歡迎有興趣的朋友共同參與！
OSSF/編述
Drupal 這個功能豐富、調整容易的開放源碼 CMS，將於 2011 年 1 月 7 日這天舉行全球串連性的發行派對。為了呼應這股潮流，Drupal Taiwan 正體中文支援站目前正如火如荼的著手號召，並尋覓適當的場地讓國內的 Drupal 愛好者能夠一同參與！歡迎有興趣的朋友們密切關注發行派對網頁的更新資訊，並於 1 月 7 日當天踴躍出席熱情同歡！
● 活動時間：2011/01/07 （五） 17:00-21:00
● 活動地點：未定、尋覓台北縣市交通方便，備有網路與簡易餐點飲料的適合場所。
● 活動網址：http://drupaltaiwan.org/forum/20101223/4781
● 主辦成員：Drupal Taiwan 正體中文支援站
[新進專案] 新進專案列表 12/27
OSSF/整理
1. dclteam717
專案摘要：our dcl final project
2. nddeagent
專案摘要：DDE Socket Agent(NDDEAgent)是一個 DDE 轉 TCP Socket的伺服軟體，是結合「StockServer」，將 DDE 的股價資訊即時的轉為 TCP Socket。
3. mcucr01
專案摘要：使用 codeigniter 為 framwork 開發 MCU 前程規畫網站。
4. taieol
專案摘要：TaiEOL
