[自由專欄] 學者的研究成果淪為出版商的生財工具－談學術作品的開放近用

學術發表是一個詭異的系統：作者沒有拿到錢，審論文的人沒有拿到錢（他們只是另一群付出免費勞力的學術人員），在某些領域，甚至連期刊編輯也沒有拿到錢，有時候作者甚至還得付錢給出版社。但科學論文的價格卻貴得嚇人。—Greg Maxwell

本校的期刊訂購經費嚴重不足，不僅既有之訂購難以持續，更遑論增訂各學科新出版期刊，從而抑制侷限了本校學術研究競爭力。—每年花 1 億 4,000 萬元訂閱期刊的臺灣大學 

任職於哈佛大學的 24 歲程式設計師  Aaron Swartz 活躍於網路社會運動、開放數位內容、自由軟體界，他在 MIT 校園用程式大量下載學術期刊，被美國總檢察長起訴，並以 1 萬美元交保。有趣的是，這些期刊的著作權擁有者 JSTOR 表示只想確認 Aaron Swartz 並未散佈這些文件，但美國聯邦政府卻執意處理此案，詳見衛報報導、Jason Kottke 的部落格報導（含有許多連結），或搜尋「Aaron Swartz JSTOR」。根據 Jason Kottke 針對本事件發表的最新文章，Aaron Swartz 的原意可能不是要解放被封鎖的學術論文，而是要大量分析這些學術論文背後的贊助單位，所以 JSTOR 才會說只要資料不外流就不追究。

不過 Aaron Swartz 被起訴一事，卻惹毛了資訊自由化的倡議人士。幾天之後，31 歲的 Wikimedia 貢獻者 Greg Maxwell 把 18592 篇創作於 1923 年之前，版權已過期的學術期刊上傳到海盜灣供大眾下載，詳見 ars technica 報導，或用「Greg Maxwell」、「18592」、「JSTOR」、「philosophical royal」等關鍵詞的兩兩組合搜尋。Gregory Maxwell 也解釋了他的動機，詳見上一帖我的翻譯。

撇開法律、技術、個人欠缺網路禮儀等細節，讓我們把焦距拉遠，問一些根本的問題：這些學術作品原本是誰的智慧？現在又變成了誰的財產？誰是竊賊？誰在促進社會進步？美國政府的作為在協助誰？是否符合公共利益？從本文的標題和 Greg Maxwell 的言行，您可以知道我們心中的答案。連著作權早已過期的學術論文，使用者都必須委屈地透過海盜灣下載，以免遭到法律騷擾，學術界的現況究竟有多麼不堪？

因為一些「奇妙」的原因，學者心甘情願簽字，將自己論文的著作權讓渡給 JSTOR 之類的期刊出版社，然後公立大學拿著公民繳的稅而私立大學拿著學生繳的學費回過頭來向 JSTOR 購買閱讀論文的有限權利。臺大每年花 1 億 4,000 萬元訂期刊，其中 8,000 萬元靠捐款得來。

繳稅、繳學費，特別是捐款給大學圖書館的公民可能從來沒想過：他們所付出用以採購學術期刊的錢，並非付給論文作者，以產生人人共享的新知；而是用於供養一個限制資訊自由流通的系統。這個系統讓某些學者躲在大學學術城牆內，比外界私人公司有更多機會與資源享用論文，再把生產的知識私有化，轉變為專利。有用的專利可以私相授受；沒有用的專利則收藏起來，變成日後創新者必須避開的專利地雷，不但阻礙創新，還讓公民被迫或自願花錢間接傷害自己。

然而個人直接損失更大的，卻是絕大多數的學術勞工學者，尤其是年輕的一輩。他們為什麼甘願放棄自己的著作權呢？獨尊論文的學術風氣力量強大，足以迫使尚未建立學術地位的年輕學者以升等和生存為重。而且即便不讓渡，學術論文也賣不到錢，留著著作權又有何益？

鮮為人知的是，學者讓渡著作權，甚至同意不在自己的網站上散佈自己的論文，會造成另一個難以量化的深層傷害：降低影響力 (impact)。上網分享文章可以換取注意力，提高 impact；簽字將著作權讓渡給 JSTOR 以換取 SCI/SSCI 點數，可以獲得客觀量化的 factor。面臨兩方衝突時，頂尖卓越大學的優秀學者往往被迫犧牲 impact，搏取 factor；被迫放棄目的，改而追逐手段。我很慶幸這帖部落格文章沒有學術價值，沒有「讓渡著作權以換取刊載在 SCI/SSCI 期刊」的選擇權。要不然連我這麼不屑學術論文的人都會很掙扎：到底我要用學術論文來對社會產生 impact，還是要拿學術論文來累積評鑑用的 factor？

學者們真的無力回應嗎？其實 Directory of Open Access Journals (DOAJ) 及 Public Library of Science (PLoS) 這兩個計畫存在已久。在臺灣，中研院創用CC計畫、政大圖資系王梅玲教授、輔大圖資系毛慶禎教授、清華大學圖書館以及圖書館界的部落格 Lib News 都曾撰文討論開放近用 (open access) 議題。其中一個具體建議是鼓勵學者在投稿至期刊前，先以「機構典藏」的方式公開在網路上，供大眾搜尋文章。可惜本校圖書館在校內推動機構典藏機制時，我感受到一般教授的冷淡甚至不信任。我認為這跟未解釋動機、走火入魔的智慧財產宣導，以及組織文化有關。不過暫時撇開個別學校的案例，在臺灣，如果學術界有大老用行動支持機構典藏，並且願意站出來說幾句話，或許有機會改觀。但是臺灣學術界的大老對這個議題有沒有興趣呢？

那些最有能力改變系統的人—那些論文卓越、期刊因其文章而生輝（而非其人因期刊而生輝）的人—卻也是這個破敗系統下受害最少的人。他們所需的資源都可透過機構取得。又因為期刊仰仗他們，他們大可要求改變標準的出版合約，而不至於因此而影響其學術卓越。其中很多人甚至不知道大眾要取得這些學術作品有多麼困難，也不知道在大學之外有哪些事情其實原本可以受惠於這些學術作品。—Greg Maxwell

在國際的層次，情況似乎比較樂觀。正好在兩個月前，萊斯大學的資訊安全專家 Dan Wallach 教授在 IEEE 的資安會議上提問道：「我們是否應該揚棄 IEEE 的著作權政策（作者讓渡權力給組織），改採 USENIX 的著作權政策（作者保留著作權後授權組織刊出）。」在場約一百五十人，只有兩人反對，其他人都贊成。Dan Wallach 教授在文中也提到對付不合理讓渡契約的三個常見做法：簽約後照舊上網發表、寄回自行修改過的契約、呼籲學會改變。Dan Wallach 將繼續在 ACM 的會議中提出類似問題，並且呼籲大家在各個場合提出相關問題，廣為散布此質疑，以期改變 IEEE 、ACM 及電機資訊領域的其他學會。

大學學者的智慧，到底是自己的財產或是公眾的財產？這是值得另文討論的問題。但不論如何強辯，「大學教授的智慧是期刊出版社的財產」是個荒謬至極的答案，特別是當這個答案出自大學教授、大學校長乃至學術大老之口。網際網路讓學術期刊出版社失去存在的意義， 或者至少必須大幅縮編。資源有限、採購清單無窮的圖書館界明白：花錢採購學術期刊是一種負擔。但在臺灣「重視數字績效甚於真實價值」的文化之下，秉持「數大便是美」的各大學高層似乎更樂於把這些數字解釋成一種業績。所以從沒聽過哪一位頂尖卓越大學校長或學術大老真心支持所屬學校的圖書館，大聲倡議支持 Open Access。當代臺灣菁英學者的缺乏遠見將成為歷史上不光彩的一頁。

我是說假如歷史文件僥倖未淪為學術期刊出版社之財產的話。

參考連結：
1. 台灣創用CC計畫尋找志工＆徵求論文 http://www.openfoundry.org/tw/foss-information/8405-cc
2. 開放近用還需要開放什麼？ http://www.openfoundry.org/tw/free-culture/8187-2010-11-18-09-23-55

[自由專欄] 「臺灣博碩士論文知識加值系統」強力徵求論文全文的網路下載與公示授權！

林誠夏／文

依照學位授予法第 8 條的規定：「博、碩士論文應以文件、錄影帶、錄音帶、光碟或其他方式，於國立中央圖書館保存之。」所以國內的碩博士生在通過學位考試後，皆被要求依照學校的行政流程，提交論文至各校圖書館，再由各校圖書館轉寄一份論文全文給國家圖書館依法保存。如此一來，國內外各地的其他研究者，將有機會透過國家圖書館這個統一的中樞系統查詢到著作人的學術創作，為畢業的碩博士生在學術領域帶來更高的曝光率、被引用率、知名度與影響力。然而您知道嗎？若沒有得到著作人的額外同意，國家圖書館所能協助傳遞知識的方式，將有很大的比例被侷限在紙本借閱的傳統模式上，這是因為著作權法「權利人保留所有權利 (all rights reserved)」的預設模式，導致國家圖書館依現行法律只能就論文的摘要進行網頁曝光，而多數碩博士生在離校時所簽署的「電子檔全文授權書」，其授權對象也多限縮在校方而不及於國家圖書館。這樣的現狀，導致國內文學、科學各領域知識的傳遞速度緩慢，並且也沒有辦法善用近年網際網路急速發展的便利性，來增裨並培植國家整體的學術研究能量。

為了處理上述的問題，現在，國家圖書館已經有了嶄新的作法可以因應這樣的情況！其於 2010 年 11 月 5 日發布了一則標題為「臺灣博碩士論文知識加值系統徵求授權說明」的聲明（註一），透過這則聲明，國家圖書館建立了讓論文原著作人可以另行授權給國圖的補強機制，透過這個補強機制，已經畢業的碩博士朋友們，將可以透過親筆簽名後免自費郵遞授權書的方式，讓國家圖書館取得將您的論文全文放置於網站公示並供人下載的資格！如此一來，這些另行簽署授權書的論文便能透過公開近用 (open access) 的方式來擴大曝光管道，另一方面，也可以讓國家圖書館能夠協助資訊弱勢的族群，以更低傳輸成本的方式取閱到這些論文，以加速知識的散布效率與流通範圍。

然而，單單簽署這份授權書，也僅是授權國家圖書館能夠合法地協助您將論文全文放置於國圖網站上，一般民眾在下載這些論文之後，若沒有原著作人的額外授權，仍然不能再續行散布或是改作這些作品。所以，若是您希望將您的論文以更自由散布或容許修改的方式釋出，則建議可以在論文全文電子檔的封面，自行添註所欲選用的公眾授權條款標誌。至於該選擇哪一類別的公眾授權條款，可以參考台灣創用CC 計畫製作的「授權精靈 (http://creativecommons.tw/choose-license)」，透過這個授權精靈頁面的操作，您將可以挑選出符合授權偏好的 Creative Commons license 來散布您的論文著作，並且也可以為這些論文增設「禁止改作」、「非商業利用」，以及「散布後必須以相同方式分享」的額外授權條件；而或者您更認同自由軟體基金會 (Free Software Foundation, FSF) 所編撰的「革奴自由文件授權條款（GNU Free Document License, GFDL，註二）」，則亦可以為您的論文採用該授權。甚至，若是您有意直接拋棄該論文的相關著作權利，亦可為其選擇宣示著作已進入無著作財產權利保護狀態的「公眾領域（Public Domain，註三）」標誌，或是選用更積極主動宣示拋棄態度的「CC0-公眾領域貢獻宣告（註四）」！

再者，要提醒讀者的是，近年來推動的公眾授權機制多數是明文規定不可嗣後撤回的（irrevocable，註五），所以若是您將所撰寫的論文，依照創用CC 或是 GFDL 授權條款向外釋出，因為這是屬於「非專屬」的授權方式，未來您仍然可以選用其他的公眾授權或商業授權的方式，來再次散布這個作品。可是，原本依照 Creative Commons 或 GFDL 授權方式散布出去的版本，是沒有辦法被嗣後取消的，這點規定請權利人務必在事前充份知悉。而若是對於 Creative Commons license 或是 GFDL 與其他相關公眾授權的方式有所疑問，建議可以查閱台灣創用CC 計畫所編撰的常見問題集 (http://creativecommons.tw/faq)，或是透過 Email 向其詢問進階的問題 (http://creativecommons.tw/contact)，此外，若是與教育領域相關著作權法及創用CC 方面的疑問，亦可逕在教育部創用CC 資訊網的諮詢服務頁面提報您需要釐清的相關資訊 (http://isp.moe.edu.tw/ccedu/service.php)。

接著，在您為論文著作選定了理想的公眾授權模式之後，藉由國家圖書館重新設計過的授權補強機制，將您的論文另行授權給國圖來進行全文流通其實一點都不複雜，以下就透過步驟化的圖示與說明指南來協助大家完成這個動作：

一、取出您自行留存的博碩士論文全文的電子檔案，並依您的授權偏好在文件首頁為其添註適當的公眾授權條款資訊與標誌。

1、圖1 為依創用CC 「姓名標示-非商業性-相同方式分享台灣 2.5 版」釋出論文的範例，紅框的部份必須清楚寫出授權方式的相關資訊，並貼上該類型 Creative Commons 授權方式的標誌，建議此一標誌圖案並可設定超連結，連結網址為該授權方式的法律授權條款頁面，此例中的連結網址即為：http://creativecommons.org/licenses/by-nc-sa/2.5/tw/legalcode，而若您信任創用CC 授權的未來演變，亦可於條款特定版本號後加上「及其後版本」這五個字，例如此例中即為「姓名標示-非商業性-相同方式分享台灣 2.5 版及其後版本」，如此一來，若是 Creative Commons license 日後再有新版本的更新，其他人便可依新版條款的授權方式來利用並散布您本來以 2.5 版釋出的作品。但若是您所上傳國家圖書館的論文僅欲提供網路下載與網站全文瀏覽，並不打算允許下載者嗣後再行散布這份著作，則便不需要額外添註任何公眾授權條款的相關標示。


▲ 圖1 依創用CC 「姓名標示-非商業性-相同方式分享台灣 2.5 版」釋出論文首頁標示的範例

2、圖2 為將創用CC 「姓名標示-非商業性-相同方式分享台灣 2.5 版」法律條款全文添附於論文附錄之範例，其實，依創用CC 授權條款的預設，添附授權條款全文併與著作本身一同散布的步驟並非必然的義務性規定，必要時可以省略之；然而，若是您欲選用的條款，為自由軟體基金會所編寫的各類公眾授權條款，例如前文提到的 GFDL，則添附條款全文與著作本身一同釋出，便為一必須實踐的義務性規定。


▲ 圖2 將創用CC 「姓名標示-非商業性-相同方式分享台灣 2.5 版」法律條款全文添附於論文附錄之範例

二、至「臺灣博碩士論文知識加值系統」徵求授權的網頁 (http://ndltdcc.ncl.edu.tw/get_thesis_authorize.php) 上傳論文全文的電子檔案並填註相關資訊

1、依序填註圖3 中以 * 號表示之必填欄位資訊。

2、按壓  之「瀏覽」按鈕，並指向您電腦裡論文全文電子檔案之路徑。

3、填註簡單的授權說明以協助國家圖書館的工作人員，能以更快的速度辨識並分類您所上傳的論文內容。

4、於  輸入該網頁隨機產生的驗證碼。

5、確定相關資訊皆填註無誤後，按壓  的「寄出」按鈕，以完成檔案的上傳。


▲ 圖3 「臺灣博碩士論文知識加值系統」提供的論文上傳網頁與步驟說明

三、親筆簽署並郵遞回傳「博碩士論文電子檔案上網授權書」予國家圖書館

1、下圖4 所示之「博碩士論文電子檔案上網授權書」可於論文全文電子檔案上傳之同一網頁下載取得，在此授權書上依序填註各項論文的相關資訊，圖4 紅線所示之處，務必要由論文著作人親筆簽名或蓋章。


▲ 圖4 國家圖書館博碩士論文電子檔案上網授權書

2、將授權書依中分線對折再對折，即可將您所填註的個人相關資訊遮蔽住，在圖5 紅框處寫下寄信人的姓名與地址。


▲ 圖5 將授權書折疊為一般明信片大小以適合郵遞

3、最後，依圖6 紅線部份的提示文字「以透明膠帶將授權書側邊黏貼好」，不需額外再自費黏貼郵票，即可依一般郵務寄信方式將授權書郵遞回國家圖書館！

4、此時整個授權流程大功告成！國家圖書館已額外取得將您論文全文上傳與網頁公示方面的資格，此後您的學術著作將可以透過國家圖書館這個儲放全國知識的中樞查詢系統，為更多人所下載參考並標記引用，而若您一併於上傳的電子檔案裡，內嵌了所選用的公眾授權條款資訊與標誌，則下載者還可以依照您預設授權方式的指示，為您續行散布或加值改作這份學術歷程上的心血結晶！


▲ 圖6 以透明或是雙面膠帶黏貼授權書側邊後即可郵遞授權書回到國家圖書館

註一：「臺灣博碩士論文知識加值系統」徵求授權的說明網頁與論文全文電子檔案的上傳網址：http://ndltdcc.ncl.edu.tw/get_thesis_authorize.php。

註二：目前最新版本的 GFDL 為 1.3 的版本 (http://www.gnu.org/licenses/fdl.html)，使用者亦可依需求選用較舊的 1.2(http://www.gnu.org/licenses/old-licenses/fdl-1.2.html) 與 1.1(http://www.gnu.org/licenses/old-licenses/fdl-1.1.html) 版本。

註三：關於 Public Domain 的顯示標誌，可參考 Creative Commons 右列網頁的例示與說明文字：http://creativecommons.org/publicdomain/mark/1.0/deed.zh_TW，而關於「公眾領域」或是「公共領域」的命名探討，可參考莊庭瑞博士所撰專文《CC專題："The Public Domain" 怎麼說？》：http://creativecommons.tw/in-depth/539。

註四：CC0 表彰的是著作的原作者，在法律許可的範圍內，拋棄該著作依著作權法所享有之權利，並主動宣示將該著作貢獻至公眾領域。此為 Creative Commons 新推行的著作權利拋棄標誌，主要是因為就法學解釋上，傳統的「公眾領域」多指因時效屆至而不再為著作權法保護的作品，或是自始就不具有著作權保護適格的法令、規章等客體，所以為了杜絕疑義，Creative Commons 近年推行 CC0 這個新創的標誌，以讓願意拋棄著作權利的權利人，能以更積極主動的方式宣告其拋棄作品權利的態度。

註五：可參照「CC-BY-3.0-台灣」的法律條款第 7 條 b 款：授權人保留依不同授權條款釋出本著作或隨時停止散布本著作之權利，惟授權人的這類選擇，不得撤銷本授權條款（或任何其他依據本授權條款已授與或必須授與之授權），且本授權條款將會全部繼續有效，除非本授權條款依據上述規定而終止。此議題的延伸討論可參考敝人與葛冬梅合著專文，「自由軟體專案授權方式的轉換（上）：不得撤銷原授權條款」：http://www.openfoundry.org/tw/legal-column-list/8195-2010-11-22-18-38-45。

[源碼新聞] 台灣駭客年會 2011－主辦者 AllenOwn、GD 會後專訪

什麼是駭客呢？一般大眾對駭客的印象來自新聞媒體的報導。新聞上不時會有網站被駭客入侵導致內部資料外洩或網站被惡搞這類的新聞報導，日前也有駭客團體宣稱要攻擊臉書的傳聞出現，種種事件使得社會大眾對於聽聞駭客一詞十分敏感，導致大眾對於「駭客」這個名詞產生負面觀感。但，其實駭客 (Hacker) 真正的原意是指對於電腦技術勇於突破挑戰、熱衷於解決問題並克服限制的人。社會大眾所認知的那群專門入侵他人網站、利用電腦來犯罪的人，其實有另一個更適當的名詞叫作「黑客、怪客 (Cracker)」，並非「駭客 (Hacker)」。而 HIT 舉辦的目的之一也是希望釐清外界對「駭客」一辭的誤解。

HIT 之所以能吸引眾多高手雲集，主辦單位精心設計的虛擬網路競賽是一大主因，在每年的駭客年會中，最令在場眾多高手引頸期盼的就是 Wargame 了。Wargame 是從國外傳來的競賽，許多國外大型資安研討會都會在議程中安排這樣的網路攻防戰競賽，此競賽是由主辦單位建置一個擬真的虛擬網路環境，讓參與的駭客可以透過這個虛擬環境練習如何進行攻擊和防禦，透過實戰演練來習得破解網站的技術。此活動不僅讓參賽者可以體會解題的樂趣，並且在實戰中學到資訊安全相關的知識和技術；另一方面，舉辦 Wargame 的用意也是希望引起企業及資安人員的注意，發掘潛藏的資安漏洞，並加以改善。

跟一般自由軟體社群大型年度活動一樣，與會者可以在這個場合中互相交換名片、結交同好並且尋求合作對象。但 HIT 比較不一樣的地方是，由於 HIT 參與者大都是從事資安領域方面的研究，因此主辦者及參與者都對於個人資料的保護都相當重視。主辦單位特別規定在會場內禁止非工作人員拍照攝影，並且開放讓大家匿名報名，繳費的程序也可以經由便利商店完成，讓真的不想透露個人資料的人也可以放心的參與駭客年會。

不難發現，Chroot 社群除了追求技術的精進之外，他們也熱切推崇自身的駭客文化，HIT 2011 主辦者 GD 說：「駭客本身是指追求技術突破與創新的人，而駭客文化代表的是駭客們的一種文化及生活態度。」或許就是因為秉持著追求創新、積極解決問題的生活態度，讓他們無論在工作時或是閒暇時，只要找到空閒時間就努力的籌備明年的 HIT，並且每年都期許突破去年的成果。而對於未來 HIT 的突破，HIT 2011 的另一位主辦者 AllenOwn 信心滿滿的說：「今年開始主辦單位希望朝向國際化發展，今年有三分之一的講場都是國外講師，未來希望國內講者和國外講者場次能各佔一半。」

[技術專欄] 利用 FreeNAS 打造儲存設備(2)－安裝篇

Weithenn (http://www.weithenn.org/) ／文

前言

在上一篇文章利用 FreeNAS 打造儲存設備 (1)－歷史篇中，我們已經了解到整個 FreeNAS 自由軟體專案的歷史由來，並下載了這次會用到的安裝與升級檔案。本次我們將安裝最新版本的 FreeNAS 8.0，開始使用圖形操作介面，並介紹 FreeNAS 的臭蟲回報系統。
 

實作環境

* 虛擬化技術平台：VMware vSphere ESXi 4.1

** 虛擬主機硬體清單：(Virtual Machine Hardware)

** 硬碟 (HDD)：2GB、20GB

** 記憶體 (Memory)：2GB

** 網路卡 (NIC)：VMXNET2 (Enhanced)

* 映像檔：FreeNAS-8.0-RELEASE-i386.iso

由光碟機安裝 FreeNAS 8.0

在本文中我們將進行實際操作，採用 FreeNAS 官網上所下載的 FreeNAS-8.0-RELEASE-i386.iso 映像檔，將該映像檔案透過燒錄機將映像檔燒錄成光碟片，並將實體主機的 BIOS 設定為光碟機開機後，將 FreeNAS 8.0 安裝於主機上；若如本文採用虛擬化平台，則必須掛載該映像檔。

在前一篇文章中，我們比較 FreeNAS 新舊版本比較表中的網路服務比較表時，讀者應該有看到其中一個名為 VMware Guest Tools 的項目，該項目表示若安裝 FreeNAS 於 VMware 公司虛擬化技術產品內成為虛擬主機時，將支援該公司的 VMware Guest Tools。這意味著運作於虛擬環境的 FreeNAS 虛擬主機，不只在自身運作方面可以得到良好的運作效率，也可以在虛擬環境的主控台上順利進行監控、應用。

在此次安裝示範環境中，我們將在虛擬化平台 VMware vSphere ESXi 4.1 中新增一台虛擬主機（Virtual Machine 或稱 Guest OS），並在該虛擬主機上安裝 FreeNAS。該虛擬主機配置了二顆分別為 2GB 及 20GB 的硬碟，2GB 的記憶體，一片 VMware 第二代加強型虛擬網路卡 VMXNET2 (Enhanced) 。配置此網路卡的目的為驗證 FreeNAS 官網中支援 VMware Guest Tools 的項目是否真的作用。眾所週知，若是安裝於虛擬化平台中的虛擬主機未支援 VMware Guest Tools 時，該虛擬主機安裝作業系統完畢後，系統將會顯示沒有抓到任何網路卡。因此我們選擇配置此網路卡，以確認 FreeNAS 是否真如官網所述進行驗證，並將此虛擬主機的網路卡置於具有 DHCP 伺服器的環境中，以便屆時 FreeNAS 安裝完畢後自動抓取 DHCP 伺服器為其配置的 IP 位址資訊。至於固定 IP 位址的設定方式，將於後續文章中進行解說。

主機設定由光碟機開機

請將從 FreeNAS 官網上所下載的 FreeNAS-8.0-RELEASE-i386.iso 映像檔燒錄成光碟片後，將欲安裝 FreeNAS 的實體或虛擬主機 BIOS 進行設定，設定為由光碟機開機，接著將 FreeNAS 8.0 光碟片放入並開機。此次實作的虛擬主機，是設定抓取該 FreeNAS-8.0-RELEASE-i386.iso 映像檔即可（這也是虛擬化平台用於測試上方便的地方之一）。

由於虛擬主機開機時間很短，常常來不及按下「F2」鍵進入虛擬主機的 BIOS 設定畫面。若您想要虛擬主機在開機時直接進入 BIOS 設定畫面，則可以設定虛擬主機開機時強制進入 BIOS 設定模式，設定方式為在 vSphere Client 中選擇該虛擬主機，接著點選滑鼠右鍵後選擇 「Edit Settings」，切換至「Options」頁籤後，點選「Boot Options」項目，接著在「Force BIOS Setup」區塊中，勾選「The next time the virtual machine boots, force entry into the BIOS setup screen.」並按下「OK」即可。設定完成後，當虛擬主機開機後會直接進入 BIOS 設定畫面，請將光碟機 (CD-ROM Driver) 設定為首要開機項目後，按下「F10 (Save and Exit)」存檔離開即可。

▲ 圖1 虛擬主機設定開機時強制進入 BIOS 設定畫面

▲ 圖2 虛擬主機 BIOS 設定畫面，設定採用光碟機內容進行開機

進入 FreeNAS 開機選單

當虛擬主機 BIOS 設定完成並存檔離開後，虛擬主機開機後，便會採用掛載的 FreeNAS-8.0-RELEASE-i386.iso 映像檔進行開機。開機後映入眼簾的第一個畫面，應為 FreeNAS 開機選單畫面，若有玩過 FreeBSD 的朋友，應該會覺得此開機選單畫面很熟悉。當讀秒倒數完畢，預設會進入 FreeNAS 安裝程序的初始化動作。

▲ 圖3 FreeNAS 開機選單

安裝或升級 FreeNAS

FreeNAS 開機選單倒數完成後，接著出現的相關訊息為 FreeNAS 進行安裝前的主機硬體相容性檢查，當該台主機硬體通過硬體檢查後則進入安裝畫面。由於目前虛擬主機的硬碟中並沒有舊的 FreeNAS 版本，因此畫面中請選擇「1. Install/Upgrade to hard drive/flash device, etc.」項目後按下「OK」，以準備進入 FreeNAS 8.0 安裝程序。後續文章中會提到若硬碟中已經存在了舊版的 FreeNAS 版本，該如何進行升級以及相關步驟。

▲ 圖4 FreeNAS 安裝選單，選擇項目 1

選擇安裝 FreeNAS 的硬碟機

接著畫面將顯示 FreeNAS 於硬體相容性檢查程序時，所偵測到安裝於主機上的硬碟。此次我們為主機配置二顆硬碟，如圖5 所示，硬碟機清單顯示為 2GB (da0)、20GB (da1)。因為本文安裝的 FreeNAS 其硬體為虛擬化平台所虛擬出來的虛擬硬碟機，因此在硬碟資訊方面顯示為 VMware Virtual disk；若為實體伺服器，則會顯示該硬碟機的品牌資訊。由於此安裝程序為選擇 FreeNAS 作業系統所要安裝的目的地硬碟，因此請選擇「da0  VMware Virtual disk 1.0 --2.0 GiB」項目後按下「OK」，以進入下個安裝程序。

▲ 圖5 選擇安裝 FreeNAS 作業系統的目的地硬碟 2.0GB (da0)

準備開始 FreeNAS 安裝程序

選擇完安裝 FreeNAS 作業系統的目的地硬碟後，接著畫面將會顯示警告訊息，內容為 FreeNAS 提醒您剛才選擇安裝 FreeNAS 的目的地硬碟資料將被清空（警告訊息 1），以及該硬碟其它未使用到的空間，也無法拿來進行分享資料的設定（警告訊息 2），因此，FreeNAS 強烈建議您將 FreeNAS 安裝於 USB 隨身碟，而 IDE、SATA、SCSI 硬碟則拿來儲存、分享資料用。

了解上述的警告訊息後按下「Yes」，則系統將開始進行安裝程序，將光碟片內的 FreeNAS 資料寫入至剛才選擇的 2GB 目的地硬碟內。如圖6 所示，您可以看到安裝進度百分比、寫入資料的速度、已花費安裝時間、預估剩餘安裝時間…等資訊，基本上 1 分鐘以內即可將 FreeNAS 8.0 安裝完畢。

▲ 圖6 FreeNAS 警告訊息及開始安裝 FreeNAS 進度資訊

FreeNAS 安裝程序完畢

當 FreeNAS 安裝程序，將光碟片內相關資料寫入至所選擇的 2GB 目的地硬碟後，安裝程序會顯示已將相關資料寫入 2GB (da0) 完成，並提醒您將安裝光碟片退出光碟機後，將主機重新啟動。按下「OK」後，回到一開始的初始安裝畫面，接著選擇「3. Reboot System」後按下「OK」將主機重新啟動。同一時間，請記得退出光碟片以利主機順利進入 FreeNAS 開機程序，而非再次進入 FreeNAS 安裝程序。

▲ 圖7 安裝程序完畢，系統提示應該重新啟動主機

▲ 圖8 選擇重新啟動項目後確定將 FreeNAS 主機重新啟動

FreeNAS 控制台畫面 (Console)

在預設的情況下，FreeNAS 主機開機後會自動啟用 DHCP Client 服務，也就是發出 DHCPDISCOVER 廣播封包尋找區域網路中是否有 DHCP 伺服器試圖取得自動配置的 IP 資訊。由於我們已經將此台 FreeNAS 虛擬主機置於具有 DHCP 伺服器的網路環境中，因此，FreeNAS 主機啟動 DHCP Client 服務時，便會順利找到 DHCP 伺服器以取得 IP 位址 (IP Address)、預設閘道 (Default Gateway)、名稱解析伺服器 (DNS Server)…等 IP 資訊。如圖9 所示，我們可以看到 FreeNAS 主機順利取得 DHCP 伺服器所配發的區網 IP 位址（此例取得 IP 位址為 10.10.25.78），並且系統提示您可以將 http://10.10.25.78 網址 (URLs) 貼至您的瀏覽器中，以登入 FreeNAS 圖形化管理操作介面。

▲ 圖9 FreeNAS 控制台畫面 (Console)

FreeNAS 主機可以順利取得 DHCP 伺服器所配發的 IP 位址及相關網路資訊後，我們可以確定 FreeNAS 確實如官網所述支援 VMware Guest Tools 功能，因此網路功能運作正常。不過若您也採用 VMware vSphere ESX/ESXi 虛擬化平台來測試，應該會眼尖地發現該虛擬主機在 vSphere Client 中，VMware Tools 項目狀態並非為全功能運作正常的「OK」，而是部份功能運作正常的「Unmanaged」狀態。造成此問題的原因，可能是 FreeNAS 團隊目前所採用的 Open Virtual Machine Tools 版本所導致，相信之後更新的版本會完全解決此一問題。

▲ 圖10 虛擬主機上 VMware Tools 所回報的狀態為 Unmanaged

測試 FreeNAS 主機網路連接狀態

在進入圖形操作介面以前，筆者建議您先進入指令模式，利用 ping 指令測試一下目前 FreeNAS 主機的網路連通狀態。請於 FreeNAS 控制台畫面 (Console) 輸入數字「7」後按下「Enter」鍵進入 Shell 指令模式，首先使用「ping –c2 10.10.25.254」指令執行 2 次 ping 指令，測試 FreeNAS 主機與區域網路中的預設閘道 (Default Gateway) 是否相通，接著使用「ping –c2 168.95.1.1」指令測試 FreeNAS 主機與網際網路上的名稱解析伺服器 IP 位址是否相通，最後使用「ping –c2 tw.yahoo.com」指令測試 FreeNAS 主機的名稱解析是否能正確運作。

▲ 圖11 測試 FreeNAS 主機與預設閘道、名稱解析伺服器及名稱解析服務是否正確運作

連通測試完成後，請接著輸入「df -h」指令來查看目前 FreeNAS 主機的檔案系統掛載情況，由目前掛載情況可以看到檔案系統為 512MB 分割區運作。至此讀者應該會感到疑惑，在上一篇中不是才說明 FreeNAS 安裝時會建立二個 1GB 的分割區，為何目前看到的是 512MB 分割區？那是因為 FreeNAS 版本從 8.0 至 8.0.1 BETA2 採用二個 512MB 分割區運作架構，為了日後功能發展性及擴充性，FreeNAS 開發團隊從 8.0.1 BETA3 版本開始，改為採用二個 1GB 分割區運作架構。因為目前所安裝的版本為 FreeNAS 8.0，因此所看到的分割區為 512MB 是合理的。進行完網路連通測試及觀察檔案系統掛載情況後，輸入「exit」指令，並回到 FreeNAS 控制台畫面。

▲ 圖12 查看 FreeNAS 檔案系統掛載情況及回到控制台畫面

登入 FreeNAS 圖形操作介面

測試及確認 FreeNAS 主機在區域網路中的網路連接狀態運作無誤後，請於跟 FreeNAS 主機同一網段的任一主機上開啟瀏覽器，在網址列上輸入 FreeNAS 主機的 IP 位址（此例為 http://10.10.25.78）來登入圖形化操作介面。正確連接 FreeNAS 主機後，瀏覽器會跳出管理者帳號及密碼的驗證視窗，預設情況下 FreeNAS 的圖形化管理者帳號為「admin」，而管理密碼為「freenas」（此圖形化管理者帳號與系統管理者帳號 root 不同，後續文章中會進行解說），在驗證視窗輸入管理者帳號及密碼後按下「Log In」鍵即可登入。

▲ 圖13 登入 FreeNAS 圖形化管理介面及管理者驗證視窗

登入 FreeNAS 圖形化管理介面後，您可以在「System Information」項目內看到 FreeNAS 主機的相關資訊，例如在 FreeNAS 8.0 版本採用的 FreeBSD 作業系統版本為 8.2 Release Patch 1、系統的主機名稱 (Hostname)、開機時間「Uptime」及系統負載狀況「Load Average」...等資訊，若想看到流量圖表可切換到「Reporting」項目。FreeNAS 採用了 RRDTool 來顯示相關硬體資訊如中央處理器 (CPU)、記憶體 (Memory)、系統負載 (System Load)、Swap 使用量、執行序 (Processes)、網路卡 (NIC) ...等的流量使用狀況。

▲ 圖14 FreeNAS 系統資訊

▲ 圖15 FreeNAS 流量統計圖表 (CPU、Memory、System Load、Swap、Processes、NIC)

由於在 FreeNAS 8.0 此一版本中，圖形化操作介面僅支援單一語系，也就是英文 (English)，從 FreeNAS 8.0.1 BETA1 版本之後，才開始加入圖形操作介面多國語系的支援。您可以切換至項目「System」接著點選「Settings」，在「Language」語系項目的下拉選單中發現，此一版本中確實只有 English 語系，並無其它國家語系可供選擇。

▲ 圖16 FreeNAS 圖形操作介面，語系切換

FreeNAS 官網教學短片

FreeNAS 官網有陸續將相關操作步驟製作成為教學短片，放至 youtube 上。在目前的教學短片清單中，與本文有關的項目為 How To Install FreeNAS™ 8 ，內容為在 Apple MAC 主機上使用 VMware Fusion 建立虛擬主機並安裝 FreeNAS 8.0 Release，在後續文章中，筆者也會適時的將 FreeNAS 官網所發行的教學短片，與筆者所撰寫內容進行搭配。

FreeNAS 臭蟲回報系統

只要是軟體開發，就一定會有臭蟲 (Bug)。FreeNAS 自由軟體專案也不例外，為了使 FreeNAS 更好，您可以將使用上遇到的問題提交到 FreeNAS 臭蟲回報系統。

FreeNAS 使用 Trac 這個優秀的開放原始碼錯誤回報系統，來管理 FreeNAS 使用者所提交的問題，以及進行臭蟲追蹤的動作。基本上，FreeNAS 會建議您先使用目前最新釋出的版本來進行測試，因為舊版的問題很可能在新版本中已經得到修復。在提交問題前，您可以先搜尋一下回報系統，避免提交重複問題進而節省開發人員的時間，也可得知此問題 FreeNAS 開發團隊預計會在哪個版本中進行修復。。

搜尋問題不需要註冊，如果您要提交臭蟲，則需要在 Trac 中註冊一個帳戶。在提交問題前，為使開發人員清楚了解您所要表達的問題，應注意相關發問禮節。例如在描述問題時應該清楚說明您採用的版本環境、操作步驟以及出現的錯誤訊息，若能配合操作步驟及錯誤訊息的抓圖則更洽當。

以筆者在測試此次的安裝版本 FreeNAS 8.0 Release 為例，當筆者欲嘗試以 Microsoft IE 9 瀏覽器來登入 FreeNAS 圖形管理介面時，雖然可以在輸入圖形管理者帳號及密碼後順利登入，但卻發現在登入後瀏覽器無法顯示相關系統狀態，如圖17 所示。

▲ 圖17 使用 Microsoft IE 9 瀏覽器登入後無法正常操作

此時筆者便開啟 FreeNAS 臭蟲回報系統的網頁，在搜尋列上輸入「IE 9」後按下搜尋鍵，便發現已經有人回報此一問題給 FreeNAS 開發團隊了。此問題項目為 GUI not working with IE9，由提交的討論串中您可以清楚看到 FreeNAS 開發人員已經回覆提交問題的使用者，說明FreeNAS 8.0 Release 版本使用的 Dojo 1.6.1 版本還不支援 Microsoft IE 9 瀏覽器，並且預計在 FreeNAS 8.1 Release 版本修復此一問題。

▲ 圖18 FreeNAS 臭蟲回報系統 GUI not working with IE9

透過上述簡要的說明，建議讀者在遇到相關問題時也可至 FreeNAS 臭蟲回報系統查詢，當您發現的問題尚無人回報時，您也可以提交臭蟲給 FreeNAS 開發團隊，以幫助開發人員了解及修正此一問題，使得 FreeNAS 作業系統能更穩定及完美。

[法律專欄] 自由軟體授權資訊的標示說明與 SPDX

[企業應用] 開放原始碼的相容與互斥性：從 Ruby 社群變更開放原始碼授權來探討

前言

Ruby 是屬於開放原始碼的物件導向程式語言，近年因 Ruby on Rails (RoR) 開放網頁應用框架的興起而廣為人知，並於 2006 年由 TIOBE 獲選為年度程式語言。

過去，Ruby 採用 GPL-2.0 或 Ruby 授權 的雙重開放原始碼授權，但從 2011 年 7 月 31 日所釋出的 Ruby 1.9.3 preview1 版本裡，筆者發現除了功能性的改進外，對於開放原始碼授權也進行了大幅度的變更。

此次 Ruby 社群將原本「GPL-2.0 或 Ruby 授權的雙重開放原始碼授權」，變更為「BSD-2-Clause 或 Ruby 授權的雙重開放原始碼授權」。其中最重大的改變，就是將 GPL-2.0 變更為 BSD-2-Clause。這引起了許多開放原始碼社群的注意，尤其是 Ruby 程式語言的開發及應用者本身，因為授權的變更將影響專案的開發模式或商業利用。

筆者從 Ruby 原始碼的版本控制系統中追蹤，發現早在 2010 年 9 月 15 日的 29262 版本號紀錄中，Ruby 社群已進行此次授權的變更。


▲ 圖1 Ruby 核心原始碼第 29262 版本號的紀錄。

在軟體專案開發過程中，不管是開放原始碼軟體或非開放原始碼軟體，除了要達到新功能的需求外，還要兼具法律授權條款的相容性要求。也就是除了要認知軟體的合法性及適用範圍外，還需要分析各軟體授權間是否存在互斥性。如果專案中，某些軟體的授權是具有關聯且互斥的，這意謂著這些軟體在法律上並不允許共存於此專案中，此時若強制進行散佈或使用，將面臨侵權的法律責任風險。

為了進一步分析此案例，筆者接下來將與讀者一起探討開放原始碼授權的互斥關係，並尋找 Ruby 社群為何要進行授權變更的原因。

 

GPL-2.0 與 GPL-3.0 的授權互斥性

自由軟體基金會 (Free Software Foundation) 明確指出 GPL-2.0 與 GPL-3.0 是彼此互斥的，這意謂著在同一專案中，該兩款授權的軟體是不得同時共存的。我們也可以從 GPL-2.0 條款原文中找到互斥的相關條文說明。

其中 GPL-2.0 條款第 4 款，

 4. 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.

以及，第 6 款，

 6. Each time you redistribute the Program (or any work based on the    Program), the recipient automatically receives a license from the    original licensor to copy, distribute or modify the Program subject to    these terms and conditions.  You may not impose any further    restrictions on the recipients' exercise of the rights granted herein.    You are not responsible for enforcing compliance by third parties to    this License.

從 4 與 6 條款中得知，GPL-2.0 是不容許在該條款外，另行新增權利與限制，否則不僅違反了 GPL-2.0 的授權聲明，使用者對於該軟體的 GPL-2.0 授權也隨即終止，也就是不得再繼續使用該軟體。然而我們在 GPL-3.0 條款中，也可以發現 GPL-3.0 相較於 GPL-2.0 的內容外，確實也另行新增了許多不同的條款內容，例如復權機制、額外添附條款，以及禁止將原始碼進行 Tivolization 的運用等等新規定，而這些新增的部分並不符合 GPL-2.0 的規定。

除此之外，Richard Stallman 本人也另行撰寫專文表述 GPL-3.0 與 GPL-2.0 之原始碼是直接不具相容性的 [註1]。因此，在 GPL-2.0 與 GPL-3.0 兩者的條款內容中，我們也可以肯定 GPL-2.0 與 GPL-3.0 是個互斥條款。

 

GNU Readline Library 6.0 的授權變更

為了鼓勵與推動新的 GPL-3.0 授權條款，自由軟體基金會逐步的將旗下 GNU 軟體專案由 GPL-2.0+ 變更為 GPL-3.0+ [註2]。這種作法可以促使（或迫使）一些軟體專案為了相容性而進行授權的變更，進而改選擇 GPL-3.0 或其它相容條款。從上一章可以了解，因為 GPL-2.0 與 GPL-3.0 的互斥性，這項改變將造成許多開放原始碼專案必須重新檢視目前所採用的授權組合是否仍然合乎授權相容性。

GNUReadline Library 是 GNU 軟體專案中的其中一項。從 2009 年 2 月 20 日釋出的 GNUReadline 6.0 及其後版本，開始使用 GPL-3.0+ 授權條款釋出。這代表著，如果 Ruby 使用 GNUReadline 6.0 或其後版本時，整個 Ruby 專案中將不得再採用與 GPL-3.0 互斥的條款，其中當然也包括了 GPL-2.0。

不幸地，在 Ruby 程式語言中，為了支援 editable command lines 的功能，函式庫在編譯時會選擇使用 GNUReadline 或是 Libedit。這些選擇可以在 Ruby 原始碼庫中的 ext/readline/extconf.rb 程式中發現。


▲ 圖2 ext/readline/extconf.rb 部分原始碼。

過去，由於 Ruby 使用 GPL-2.0 與 Ruby 授權的雙重開放原始碼授權釋出，再加上 Ruby 授權與 GPL（無論是 GPL-2.0 或 GPL-3.0）存在著互斥不相容性。所以當 Ruby 在編譯時若選擇 GNUReadline，則最終授權還可以由雙重授權轉變為 GPL-2.0 的單一授權；反之，若選擇 Libedit，則最終授權也可以轉變為 Ruby 授權的單一授權。

但是若繼續使用 GNUReadline 6.0 及其後版本時，會因為 Ruby 本身授權的關係，不僅最終無法以 GPL-2.0 授權釋出，也無法以 Ruby 授權來釋出。這使得 Ruby 的散佈者面臨了侵權的風險。

社群為了因應 GNUReadline 6.0 及其後版本授權變更的互斥性，被迫於 2010 年 6 月 1 日的 28118 版本號中，在 ext/readline/extconf.rb 程式加入了拒用 GNUReadline 6.0 及其後版本的判斷條件。


▲ 圖3 Ruby 核心原始碼第 28118 版本號的紀錄。

如此的作法，確保了 Ruby 若繼續使用 GNUReadline 時，會主動避開 6.0 及其後版本，使得最終授權仍可變更為 GPL-2.0，而暫時解決了授權互斥性的問題。

在此過渡時期，Ruby 開發者彼此間持續討論著授權議題。直到 29262 版本號時，才將 Ruby 的授權變更為「BSD-2-Clause 或 Ruby 授權的雙重開放原始碼授權」，並於 2010 年 9 月 15 日的 29264 版本號中，將先前拒用 GNUReadline 6.0 及其後版本的判斷條件去除。


▲ 圖4 Ruby 核心原始碼第 29264 版本號的紀錄。

此後，Ruby 專案終於可以繼續自由選擇 GNUReadline 或是 Libedit，而不用再擔心授權互斥性的問題。

 

Ruby 社群為何不選擇 GPL-3.0+ ？

其實除了上述的選擇外，Ruby 社群還可以有別的選擇，例如全面升級為 GPL-3.0+。

也就是如果 Ruby 變更為 「GPL-3.0+ 或 Ruby 授權的雙重開放原始碼授權」。在編譯時選擇 GNUReadline 時，最終授權將可由雙重授權變更為 GPL-3.0+ 的單一授權；反之，若選擇 Libedit 則最終授權將可由雙重授權變更為 Ruby 授權的單一授權。如此先前遇到的問題依然可以解決，但又為何 Ruby 社群選擇的不是 GPL-3.0+ 而是 BSD-2-Clause？

這個問題的答案可以從「Change Ruby's License to BSDL + Ruby's dual license」的討論串中得到解答。

根據 Naruse 的說法，選擇 BSD-2-Clause 授權條款時，開發者不僅可以繼續使用 GPL-3.0 的軟體，也可以把原本是 Ruby 授權的程式改由 BSD 授權來撰寫。當然，除了 Naruse 在該文中所述的優點外，筆者認為這個改變還帶來了其它的優點，如：

－因為 BSD-2-Clause 授權條款相容於 GPL-2.0 及 GPL-3.0。所以開發者不僅可以繼續使用 GPL-2.0 的軟體專案，也可以選擇 GPL-3.0 的軟體專案。這擴大了開發者擁有的選擇性，但最後仍然要確保最終的授權是否具互斥性，也就是在同一專案中，要避免同時選用 GPL-2.0 與 GPL-3.0。
－更有利於整合其它與 GPL 互斥的開放原始碼授權條款的軟體專案，以納百川，成其大。

 

結論

在此案例中，我們可以看到一個正確處理授權互斥的流程。

1. 當發現專案授權衝突發生時，馬上進行排除或隔離。本案中 Ruby 社群將 GNUReadline 6.0 及其後版本先行排除。
2. 專案成員進行理性的討論，並重新選擇一個最適合專案的授權組合。
3. 最後修正專案授權聲明，並恢復先前處理的狀態。

在 Ruby 社群中，筆者看到了一種不同的開放心態。與其它軟體專案不同的是，他們並非將授權變更為常見的 GPL-3.0 或 GPL-3.0+，而是回頭探究本身專案的特性以及未來發展的需求，最後選擇了一個最適合自己的授權組合－BSD-2-Clause 或 Ruby 授權。這項調整不僅為開發人員帶來了更多的選擇權利，也使得 Ruby 更可以容納更多不同種類的開放原始碼授權專案。
 

註解

註1：「[Why Upgrade to GPL Version 3](http://gplv3.fsf.org/rms-why.html)」。專文第三段："When we say that GPLv2 and GPLv3 are incompatible, it means there is no legal way to combine code under GPLv2 with code under GPLv3 in a single program. This is because both GPLv2 and GPLv3 are copyleft licenses: each of them says, “If you include code under this license in a larger program, the larger program must be under this license too.” There is no way to make them compatible. We could add a GPLv2-compatibility clause to GPLv3, but it wouldn't do the job, because GPLv2 would need a similar clause."

註2：加號(+)意謂著「後續版本」(or later)。如 GPL-2.0+ 代表 GPL-2.0、GPL-3.0 及未來新的 GPL 授權版本；而 GPL-3.0+ 代表 GPL-3.0 及未來新的 GPL 授權版本。

 

相關連結

Ruby 官方網站 http://www.ruby-lang.org/

GPL-2.0 授權全文 http://www.gnu.org/licenses/gpl-2.0.html

Ruby 授權全文 http://www.ruby-lang.org/en/LICENSE.txt

BSD-2-Clause 授權全文 http://www.opensource.org/licenses/bsd-license.php

Ruby 原始碼版本控制庫 http://www.ruby-lang.org/en/community/ruby-core/

GPL-3.0 授權全文 http://www.gnu.org/copyleft/gpl-3.0.html

GNU 軟體專案清單 http://www.gnu.org/software/software.html

GNU Readline Library 官方網站 http://www.gnu.org/s/readline/

Libedit 官方網站 http://sourceforge.net/projects/libedit/

報主的話