關於本報

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

近期電子報


訂閱便利貼


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

自由軟體鑄造場電子報
發報時間: 2012-01-18 05:00:00 / 報主:OSSF
[公益聯播]【志工招募】志願服務教育訓練
本期目錄
[技術專欄] 與 PHP Fog 的第一次親密接觸 - OpenFoundry
[技術專欄] Heroku──Ruby 程式語言的最佳雲端環境
[技術專欄] Python/Django on Heroku
[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析
[源碼快訊] 自由軟體校園演講 Call for Presentations
[源碼新聞] 開源創新:從軟體專利與 Android 平台談起 - 自由軟體授權應用與商業建議二十講系列之五會後報導
[源碼新聞] 歲末年終大掃除,維基冬聚談除錯
[技術專欄] 利用 FreeNAS 打造儲存設備 (8)──網路設定篇之頻寬合併
[法律專欄] 化簡為繁的 Apache-2.0 授權條款
[企業應用] 透過 oDesk 建立虛擬團隊
[自由專欄] 電子書包在臺灣:產品掛帥,專業無奈
[自由文化] 什麼是「開放資料」?
[自由文化] 開放政府資料營
[自由文化] 維基化.話維基(5)-「官方」的迷思
[接案 / 工作] PHP Senior Developer – Zalando Taiwan
[接案 / 工作] PHP Junior Developer – Zalando Taiwan
[技術專欄] 與 PHP Fog 的第一次親密接觸 - OpenFoundry
2012-01-04 14:22 作者是 [NISRA] Loyo, Snake/文;[NISRA] Allen Own/技術指導

前言

相信許多人都有開發 PHP 的相關經驗,豐富的資源及其便利性皆為不可忽視的優點,程式本身撰寫起來也相對容易,相較之下環境建置及部署反而成為許多開發者的困擾。PHP Fog 透過 PaaS 的方式減輕了開發者在這方面的負擔,透過幾個簡單的步驟便將開發時所需的環境及資料庫設定完成,並且提供許多 Framework 可直接選用,讓開發者能更專注於程式開發。以下將透過 PHP Fog 平台簡易實做 PHP 程式開發。

[技術專欄] Heroku──Ruby 程式語言的最佳雲端環境
2012-01-06 09:00 作者是 高見龍 (Eddie)

您曾經用 Ruby on Rails 開發網站,但在國內找不到可以用的主機空間嗎?或者您是新創公司,但初期還沒有足夠的資金投資伺服器的硬體設備嗎?又或是沒有專職的 MIS 幫您管理伺服器?讓我們來看看 Heroku 吧!

[技術專欄] Python/Django on Heroku
2012-01-05 09:27 作者是 小海

簡介

自從 Heroku 出現之後,筆者挺羨慕 Rails 的開發者有這麼酷的服務可以使用。不過就在不久前 Heroku 也開始支援 Python 了,便趁著空閒玩了一下。大體而言只要熟悉平常使用的 Python 相關工具,像是 virtualenv、pip 以及 git,整個部署流程就很簡單。

本文將說明如何透過幾個簡單的步驟,把 Django 部署到 Heroku,手腳快的話十分鐘之內便可以看到網站在 Heroku 上運作了。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析
2012-01-13 18:01 作者是 OSSF電子報團隊

為達到有效的提供讀者所需之資訊,自由軟體鑄造場電子報在歲末將近之際,設計 2011 年度問卷以尋求讀者的意見回饋。感謝各位讀者踴躍回饋,給我們一個能做得更好的機會。本網路問卷是採隨電子報一同發佈連結的方式,總共獲得 44 份問卷之意見回饋,電子報編輯們在經過一連串的分析討論後,得出未來可以做得更好的方向,並且我們也會在文末針對讀者所給的建議做回應。

整份問卷共有 題,1~6 題為讀者基本資料調查,7~10 題為讀者使用習慣,11~17 則是讀者滿意度調查。首先,透過下圖我們可以發現,閱讀自由軟體鑄造場電子報的人有高達九成為男性,而年齡層主要在 30~39 歲之間。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

從以下數據可以得知,電子報讀者以從事資訊軟體的人為最多,其次是學校或其他非營利性質之研究機構,再來是資訊硬體業。另外,在興趣與專長方面,Programmer/程式設計、MIS/網管系統管理、軟體開發依序位居前三名。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

從第 8 題的調查結果來看,我們可以觀察出讀者的使用習慣,大部份人都是訂閱電子報 Web 版,再連結到 OpenFoundry 主網站閱讀文章。另外,值得一提的是 OpenFoundry Facebook 非官方粉絲團是去年八月才成立的,但使用臉書來 follow 本電子報文章的人也有一定比例。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

第 12 題的結果也呼應到前面第 5 題的讀者所在領域和讀者興趣/專長。有 50% 的讀者最常點擊技術專欄文章,這個發現也跟本電子報的經營方向一致,一直以來我們都以技術專欄為主推,從去年十一月開始則不定期的推出技術專題系列,使技術文章更有系統性的呈現。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

從第 13 題可以得知,有 59.9% 的人認為本報技術專欄是最令人滿意的專欄,再來很明顯得可以看出介紹軟體應用的源碼秘技位居第二。就第 14 題而言,最多人認為企業應用(企業採用策略探討)這分類有待改進。本電子報確實在企業應用方面題材的文章,其數量上較為缺乏,在未來的一年裡,我們也會盡力去經營、認識相關方面的人脈,邀請他們撰寫相關專文,以符合讀者需求。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

根據第 16 題的數據,選擇 [符合] 與 [非常符合] 的讀者比例大約佔 57%,表示有超過半數的讀者都認為本電子報很符合他們心中的期待。雖然如此,電子報編輯們仍覺得選擇 [尚可] 選項的讀者的意見非常的重要,這會是讓我們更進步的動力,因此接下來,我們會針對第 17 題讀者給的寶貴建議做回應。

[源碼快訊] 「2011 年度電子報讀者滿意度調查」問卷結果分析

讀者建議:

有讀者表示,技術專欄缺乏次分類,不方便讀者進一步閱讀其他相關文章。

→ 針對這點,電子報編輯們也已經在著手規劃次分類具體的作法。本電子報是以技術為主的刊物,從自由軟體鑄造場計劃成立之初累積至現在,技術文章的資源已經相當豐富且數量可觀,增加次分類的規劃不僅可以對於讀者的便利性大大提升,更可以讓這些珍貴的資源有效地被再次利用。感謝讀者具有建設性的建議!

→ 有讀者指出,希望技術文章可以多介紹一些在非 Linux 環境下也能使用的跨平台的技術,讓在不同環境下的人都可以使用電子報中介紹的 OpenSource 工具。

→ 關於讀者的這個需求,我們會勤加改善。考量到實際情形,確實有很多人是使用非 Linux 環境,但也想使用 OpenSource 工具。未來電子報將會提供更多元的內容,以符合各種不同平台讀者的需求。感謝讀者的不吝賜教!

[源碼快訊] 自由軟體校園演講 Call for Presentations
2012-01-16 14:52 作者是 林珈宏

自由軟體鑄造場校園演講徵求講者,歡迎有志至大專院校分享開發心得、從事自由軟體教學、推廣自由軟體的朋友們,能加入校園推廣演講的行列,將您的知識、理念及熱情貢獻給學校師生!

詳細說明

作為自由軟體校園演講的媒合平台,OSSF 會將相關的講題、大綱等資訊提供給學校師生(參見此頁面),讓師生選擇與課程教學有相關的若干講題,再由 OSSF 與講師連繫,就演講日期、地點及相關事項進行討論;討論出結果後,OSSF 即向提出申請的師生確認該場演講。演講日,OSSF 校園推廣負責人也會與講師一同前往出席,讓講師可專心準備演講內容。

聯絡方式

如果您有意願擔任校園演講的講師,可依下列方式回覆:

回覆格式

  1. 講師姓名:
  2. 講師簡介:
  3. 講  題:
  4. 議程大綱:
  5. 議程時間:
  6. 參考資料:

  7. 聽講對象:
  8. 簡報授權方式:
  9. 是否同意錄影:
  10. 錄影授權方式:
  11. 其他需求:

回覆說明

  1. 講師簡介一欄,若講師願意留下聯絡方式或社群帳號,也將置於此處。
  2. 可提供多個講題;每一講題須搭配一個議程大綱。
  3. 參考資料一欄,可放置若干網頁連結,供聽講者預先閱讀學習;若無,亦可不填。
  4. 聽講對象一欄,可標明本議程適合資工系(資管系)幾年級以上、碩士班學生,或是已上過哪些課程的同學來聽講,讓聽講對象更能有效學習;若講師將以申請對象客製化演講內容,亦可不填。
  5. 您的簡報將置於 OSSF 校園演講頁面供公眾下載,故請選擇您欲採之公眾授權方式;若您對於公眾授權方式不甚了解,請洽 OSSF 校園推廣負責人。
  6. 建議您以開放格式釋出您的簡報。
  7. 若您同意錄影,您演講之錄影檔將置於 YouTube 供公眾觀看,並請選擇您欲採之公眾授權方式。
  8. 其他需求一欄,可自由填寫任何您對於 OSSF 安排校園推廣的相關期待及想法。

來信

  • ossfschool AT openfoundry.org
  • 來信標題:自由軟體校園演講 Call for Presentations - (您的名字或 ID)

來電


關於自由軟體校園演講

OSSF 從 2006 年迄今已進行了超過 180 場次的自由軟體校園演講,其中除了 OSSF 同仁之外,也包括了自由軟體社群朋友及運用開放源碼經營者的貢獻投入。


[源碼新聞] 開源創新:從軟體專利與 Android 平台談起 - 自由軟體授權應用與商業建議二十講系列之五會後報導
2012-01-16 16:02 作者是 林懿萱

自由軟體鑄造場(以下簡稱「鑄造場」)在之前的「自由軟體授權應用與商業建議二十講系列之四」- 挑選了「GPL 的授權規則與技術工程遵循之道」為主題,在那之後,因蘋果電腦控告宏達電生產的 Android 手機侵害其專利權,使得軟體專利的相關議題,受到國內產學各界更多的關注,因此 2011 年末,鑄造場特別針對自由開源軟體與軟體專利議題,邀請到國內外的專家學者,一起為活動的與會者解析這個主題。

演講一開始由中央研究院資訊科學研究所與資訊科技創新研究中心合聘的莊庭瑞教授開幕致詞,接著由政治大學法律科際整合研究所暨智慧財產研究所合聘的李治安教授簡介軟體專利的基本概念,最後則進入本次演講主題,由國際知名專利組織 Open Invention Network (OIN) 執行長 Keith Bergelt 先生帶來「開源創新:從軟體專利與 Android 平台談起」的專題演說。

在李教授的開場部份,首先從軟體產業和智慧財產權的關連談起。他提到在 1970 年代之前,大部份軟體無法單獨獲得專利保護,通常會就軟體所附著的機械設備一起來取得專利保護;而在 1970 年代之後,專利保護還是以硬體裝置為主要保護對象。但這樣的狀況在 1990 年代之後有了改變,90 年代之後在美國軟體開始可以獨立於硬體之外取得專利。接著李教授談到軟體專利的政策爭議,對於軟體專利之所以在各國引發這麼多爭議,他提出了幾個討論的要點。最後,李教授再談到歐洲和美國軟體專利的發展。歐洲相對於美國,對軟體專利的態度是比較保留的。歐洲專利公約(European Patent Convention,簡稱 EPC)在第 52 條第 2 項 d 款和第 3 項,對軟體可否取得專利設有細部規範。其規定,純粹的電腦軟體程式或純粹的商業方法,不得取得專利,除非該軟體技術符合例外規定,就是若軟體程式和硬體結合、且存在技術特徵,可解決過去沒法解決的技術問題,那才有機會符合專利核可的要件,例外地取得這個高度軟體性質的專利。

相對於歐洲,美國軟體專利的發展則比較複雜。美國最早和軟體專利相關的案子,是 1972 年 Gottschalk v. Benson 案,當時學界和實務界對這個案子的見解是,只要有軟體程式或數學演繹法在裡面,就不能取得專利。但 1978 年 Parker v. Flook 案裡,法院持與前不完全相同的見解,Flook 案雖仍指出純粹數學公式不得申請專利,但其亦特別指出,若用軟體程式來呈現一數學演算法,只要該演算法符合專利要件,即符合新穎性、實用性、非顯著性,那還是有可取得專利的可能性。再來是 1981 年 Diamond v. Diehr 案,法院對該案的見解是,自然界的基本法則包含數學公式,不可寫在專利的請求項中,但若奠基在此基本法則上,有另一個具應用性質的新穎技術,且此應用過程符合專利要件,則還是可以例外地核可專利。前面三個案子因為皆上訴到美國聯邦最高法院 (Supreme Court of the United States),所以對全國皆有拘束力。但上述的見解到了 1998 年的 State Street Bank & Trust Co. v. Signature Financial Group, Inc. 一案後,有了很大的轉變,此案是美國巡迴上訴法院(United States Court of Appeals for the Federal Circuit,簡稱 CAFC)的判決,雖是第二審級的判決,但具有非常重要的指標性意義,因其對於一般地院的專利案件,有專屬的管轄權;CAFC 對此案的判決是,前述 1972、1978、1981 年三案的法院見解,所謂數學演算法及商業方法不具專利適格是錯誤的,CAFC 認為,只要產生「有用、具體,且有形的結果」便可申請專利;其後、CAFC 在 2008 年 Bilski v. Kappos 一案中,建立了「機器或轉變測試法 (The machine-or-transformation test)」的判準,此判準指出,一個商業方法欲申請專利,必須要與特定機器或裝置相連結,或將特定物品轉變為不同狀態或事物。不過此一判準在 2010 年同案上訴到聯邦最高法院時再經修正,聯邦最高法院認為「機器或轉變測試法」可以是判斷專利適格的輔助工具,但並不能作為唯一判斷標準,其認為如果軟體程式執行過程,或是商業方法運作過程,仍然偏近一般抽象思考或是人類心智活動,則還是不應讓其取得專利。

在李教授對軟體專利進行精要的解說之後,活動正式進入本次的演講主題。Bergelt 先生的演講分成兩大主軸,一是說明現下專利體制如何影響創新的實際情況,另外則說明開放源碼及 Linux 如何引領嶄新的應用模式及智慧財產權的配套管理。

Bergelt 先生首先提到,現時美國產業界所倚賴的創新能量,其實並非全由美國一地所產出,而是聚集了全世界人類的智慧結晶。回頭看過去這 20 年矽谷的歷史,會發現百分之八十在矽谷的公司,原先多是在美國境外設立,然後再移居矽谷進行更大規模的發展。所以美國的科技產業能有如此的創造力,其實多所仰賴來自全球各地人們的創新能力!而和矽谷情況類同,開放源碼的運作方式,能海納百川,聚集全球社群的智慧,並擁抱全部的創新者。此外,我們也必須瞭解到,當今的商業競爭,並非是不同科技平台間的競爭,而是彼此不同創新方式的競爭,亦即是封閉、控制、有限的創新,與開放、動態、任何人皆有能力創造這兩種模式的競爭。貫穿過去整個 90 年代,產業界的發展主軸是「客製化」的觀念,在這個觀念底下,所創造的設備裝置因為所使用的人、所隸屬的文化不同而有差異,而現在開放源碼的運作方式,能夠更因應這樣的需求,讓產業界及使用者,加速地往客製化的方向邁進。

Bergelt 先生認為從演變上來說,自由開源軟體的發展是一個社會趨勢!而不僅單單是一個科技方法的變革。如果只是一項科技方法,那在產業市場上是很容易被攻擊和取代的,但社會趨勢是無形的、看不見的,經過社會長期發展而形成的趨勢,這樣的趨勢一旦開展後就很不容易被阻扼。開放源碼是全世界的人共同參與一個專案,群聚一起創造並回饋所創造出來的東西,透過這樣不間斷創造與回饋的循環、1+1+1 不再只等於 3,1+1+1 可以創造出 10 或是 30 的價值,因為這樣的模式可以讓大家將彼此的智慧成果加入匯集,當成果逐漸累積之後,也會吸引許多公司試著接觸、運用開放源碼的專案,這些公司多數並非市場上的龍頭公司,也同樣都是以賺取利潤為營運目標,然而、從智慧財產的角度出發,使用這些自由開源創新科技時必須要認知到,眾人所創造出來的智慧財產在受到法規保障的同時,也會一併受到法規所規範,這兩件事是同時並存的。例如專利保護制度就是一個既存的制度,不僅在美國、在歐洲也有數以千計的軟體被給予專利保護。舉 Richard Stallman 先生為例,Stallman 先生是從比較理念性的角度來看自由軟體的發展,其認為多數人太倚賴法條規定來看智慧財產權利,然而、現行制度畢竟是目前產業界利用自由開源專案所必定會碰觸到的現實環境。

以美國市場上的專利訴訟和專利蟑螂 (patent troll) 問題為例。許多商業公司在面對手機戰場中的競爭對手時,對授權、談判興趣缺缺,而會依據專利權利直接向 ITC (United Stated International Trade Commission) 提請調查。此種手段會令被控方在訴訟過程中支出許多人力、時間、金錢等訴訟成本,並可能對公司形象帶來損害,在最糟的狀況下,還可能收到禁止產品繼續販售的禁制令。專利蟑螂利用了這樣的制度,讓受控方即使最後贏了訴訟,但整體成本評估下,實質上是輸了這場官司,種種這些因素,都直接或間接造成了專利蟑螂壯大的現況。也可以說美國這樣獨特的專利訴訟制度,難以數計的高額金錢不是被用來支持科技的創新與研發,而是被用來鼓勵利用專利進行套利的行為。與此類同,諸如微軟、蘋果電腦等大公司,因為有龐大的資本做為後盾,所以可以藉訴訟作為手段來對付無力負擔訴訟費用的小公司。這些大型企業提起司法訴訟,不一定要贏,單單訴訟的過程就可以將那些沒多餘人力、財力應付訴訟的競爭對手逼到絕境。所以現實是,這世界上存在許多專利蟑螂類型的公司,只要你從事技術研發,就很難完全免於專利涉訴的風險。

而在自由開源軟體專案的領域中,也並不免於專利訴訟的風險範圍!這邊可以舉 Linux 作業系統與相應而生的保護組織 OIN 的運作方式為例。一直以來,不乏專利蟑螂以其擁有的專利為訴訟手段,試圖影響 Linux 作業系統的未來發展。這並非因為這些專利蟑螂擁有的專利都恰巧與 Linux 相關,而是因為 Linux 專案具有眾人共工參與、協同開發的特質,而由眾人分別寫入與匯進的技術方法很多,所以也很容易成為專利蟑螂攻擊的目標。而 OIN 就這樣的風險所採取的因應方式為,透過購買相關專利及提供免費授權,來支持與穩定開放源碼和 Linux 作業系統的持續發展,並藉此削弱專利蟑螂的影響力。OIN 本身並不營利,其專利授權的方式是以免授權金的方式進行,任何的自然人或是法人都可以是 OIN 的被授權人,但前提是,該被授權人必須同意不會對 Linux 社群的任何成員提起專利訴訟,再者、若是其所擁有的專利,經 OIN 認定是與 Linux 作業系統相關的話,該被授權人亦須同樣願意以回饋、非專屬授權的方式提供給 Linux 開發社群使用。也就是說、在自由開源軟體專案的領域裡,還是會有專利侵權的各種爭議,此時可以透過專利收購、互惠授權的方式來處理,並且透過互惠組織提供相關資訊,讓採用自由開源專案來進行產品販售的公司知道,哪裡可以取得資源,可以取得哪些資源,以及面對這類型的相關訴訟時,可以採取的防禦手段為何,及不該採用的高風險作為又有哪些。

最後、Bergelt 先生在結論中提到,自由開源專案及 Linux 作業系統的採用,對於心態上拒絕參與開放源碼活動的公司來說,感受上是種威脅。因為對那些公司來說,轉變營運模式與開發方式是痛苦的,客觀上來說,對於很多商業公司來說,他們有資源、有財力可以進入開放源碼的世界,但現階段出數企業仍然不知道要用什麼途徑參與,並且也常常誤以為產品的散布方式,在開放源碼與封閉模式之間只能擇一,而不瞭解其實只要佈局得當,不同產品的散布模式有機會可以選擇既開放又封閉。而完全抗拒開放源碼潮流的公司,將會因為堅持他們一貫封閉的作事方式而倍感艱辛,同時也可能淪為故步自封的少數產業,因為當今的世界,任何事都會受到自由開源專案的影響。只要身處科技領域,這個應用情勢已經是無可逆轉的現實。

而會後、Bergelt 也於接著的 QA 時間中,回答當場與會朋友的各項提問,例如以 Red Hat 與 Google 持有若干關鍵專利的例子,來說明為何許多大型的自由開源軟體商用公司,會利用現行的專利制度來構築自身的專利保護層,這大抵也就是呼應現行規範的現實,若手上完全不持有專利,則在專利訴訟發生時,很難去保護相關開源專案的未來發展。

這次演講的簡報檔及錄影檔可參考右方網址:http://www.openfoundry.org/tw/activities/details/182-open-source-innovation-patents-and-the-android-platform-in-perspective,自由軟體鑄造場往後亦會持續,就國人感興趣的自由開源議題陸續舉辦專題工作坊,有興趣的朋友可在自由軟體鑄造場的「活動」頁面上更新各分類的活動訊息!
[源碼新聞] 歲末年終大掃除,維基冬聚談除錯
2012-01-16 14:19 作者是 Reke

2012 年 1 月 7 日,再過半個月左右就是農曆新年的到來,也是維基百科台灣社群 2011 年冬聚的日子。在歲末年終的時候,來個除舊佈新是華人的習俗,中文維基百科將近 40 萬的條目,也需要好好的清理一番了。比起英文維基百科來說,中文維基百科的條目素質往往不是那麼令人滿意。因此許多維基百科的編者、讀者,就在這場盛會中,一起來探討如何能夠為維基百科除錯,讓內容更完善。

維基編輯經驗談,收穫滿滿

上午時段率先開場,是由 2006 年起就投入編輯的 Supaplex 進行為時半小時的專題演講,題目是「為何犯錯?怎樣除錯?」。Supaplex 先從各方對維基百科的想像切入,勾勒出維基百科「協作」觀念的實際運作方式,再從寫作者的專業性、視角的侷限等等方向,分析出錯的種種原因。最後再提出多項建議,從個人對資料的收集到尋求其他維基人的協力,給予在場參與者許多實用的參考。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖1 Supaplex 的專題演講。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

緊接著登場的是「條目維護面面觀」座談會,由三位活躍的維基編輯者擔任來賓,從條目維護實際經驗的分享,讓所有在場的參與者能了解維基社群在條目維護上嘗試過的多種方式,以及面臨到的難題。

魔法設計師」是台灣最早參與百科編寫的資深維基人之一,分享了早期「台灣主題」頁面,由幾個朋友聯合,共同更新特定條目的經驗。他認為現在網路溝通的平台更多更便利,要發起這樣的合作更方便;然而也因為方便的工具太多,反而造成力量的分散。如何克服缺點保留優點,給有心協作的維基人提出一個值得思考的方向。「TX55」則是主要以單打獨鬥為主,但是喜歡寫 ACG 主題條目的他,在創作過程中也有碰到 ACG 專題成員主動參與協助。他從個人條目創作者的角度,也提出了對群體協作機制的見解。「安可」則是目前「條目質量提升計畫」的總主持人,不但分享了多種形式的合作經驗,同時也注意到討論氣氛對於協作平台是否活躍有一定的影響力。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖2 座談會講師,由左至右分別為魔法設計師、TX55、安可以及主持人 Reke。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖3 座談會實況,TX55 的分享。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

創意討論火花多,跨國研究眼界開

經過一個上午的分享,不管是已經參與過編輯的老手,或是從未有編寫經驗的讀者,都對維基百科的除錯機制有了認識以及新的思考。因此下午的時間,就以類似 Unconference 的型式進行了一個小時的創意討論會。會中主要觀注三個焦點,第一是如何讓更多的專家願意參與維基百科的編輯,第二是如何建立更容易協作的平台,第三則是如何協助編者解決資料搜集的困難。與會者無論參與維基編輯資歷的深淺,都在主持人的引導之下,由自身經驗出發找出問題,並在集思廣義的情況下提出可能的創意。

雖然短暫的討論時間並沒有辦法提出完美的計劃,然而在熱烈的氣氛之中仍然併發出許多創意的火花。例如在促進專家投入維基的方法上,與會者認為要讓忙碌的教授投入維基寫作有一定的難度,但是可以從吸引研究生的編輯興趣為主,藉由師生的關係引入專家級的識見;至於吸引學生族群投入編輯的方法,則可以考慮透過網路媒體的宣傳塑造出明星化的維基人,激發參與者的榮譽感。又例如在討論如何建立協作平臺的小組,試著在列舉出理想平臺的條件之後,把網路上常見的服舉務拿來「超級比一比」,為它們各項條件打出分數;經過數據化的衡量,精挑細選出郵件群組服務做為目前最理想的協作小組溝通平臺,為社群未來建立合作機制,提供了相當具有參考價值的建議。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖4 分組討論實況-那些年,一起寫的維基。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

有了台灣維基社群的創意激盪,本次活動更進一步擁有了國際級的視野。出生德國、目前在維基媒體基金會 (WMF) 服務的 Tilman Bayer,透過中文現場口譯,提供了「關於維基百科可信度的學術性研究」簡報。簡報中指出英文維基百科的條目雖然可能有一些深度不足的問題,但是在資料正確性上,許多領域都有極佳的表現,堪與專家編纂的工具書匹敵。雖然報告中指出,針對其他語言版本的研究資料目前仍不足,但是英文維基的輝煌成果仍可做為中文維基百科的編輯者追求的目標。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖5 Wikimedia Foundation 負責 movement communications activities 的 Tilman Bayer 來到活動現場演講,題目是「關於維基百科可信度的學術性研究」。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

大小維基聚會,邀您一起參與

雖然精彩的冬聚活動已經結束,但是對於維基百科除錯、提升品質的工作,這只是一次開端而已。擁有近 40 萬條目的中文維基百科,內容的生產、編輯、排版、修正、維護、更新等工作,都是由志願者無償投入時間心力來完成。因此需要更廣大的編輯隊伍,才能夠更全面地改善所有條目的品質。目前台灣已有台北台中兩地社群有固定的聚會,南部的台南社群也力圖重啟聚會。這些小型但頻率較高的地方聚會,除了維繫維基人的感情之外,也肩負著編輯技巧分享的任務。錯過了這次的聚會沒有關係,記得到維基百科上注意台灣各地社群聚會的消息,只有透過您的熱情參與,才能讓中文維基百科成為最可靠的網路工具書。

[源碼新聞] 歲末年終大掃除,維基冬聚談除錯

▲ 圖6 活動大合照。出處:Wikimedia CommonsHarenwang 拍攝,採用 CC-BY-SA 3.0 Unported 授權。

作者簡介

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

[技術專欄] 利用 FreeNAS 打造儲存設備 (8)──網路設定篇之頻寬合併
2012-01-13 10:26 作者是 Weithenn ( http://www.weithenn.org/ )

前言

本文將實作如何建立 Lagg 虛擬網路介面,並採用 LACP 方式,讓 FreeNAS 主機啟用網路卡頻寬合併功能 (Link Aggregation),也就是 IEEE 802.3ad (Link Aggregation Control Protocol, LACP),同時也將設定 FreeNAS 主機網路卡啟用 Jumbo Frame 功能,以便在 FreeNAS 主機進行大檔案(例如影音檔)傳輸時,能減少主機運算負載並加快傳輸時間,且於相關功能設定完畢後進行成員網卡故障及 Jumbo Frame 大封包測試。

[法律專欄] 化簡為繁的 Apache-2.0 授權條款
2012-01-13 11:51 作者是 林懿萱

若是把常見的自由軟體分成三類:對使用者限制甚少的 BSD 類、以 Copyleft 的授權拘束性著稱的 GPL 類、及不屬於前述兩類的其他類,則 Apache Software Foundation(簡稱 ASF)推出的 Apache 授權條款會落入 BSD 類中。而 Google 的 Android 作業系統雖以 Linux 為基礎,但卻選擇與 Linux Kernel 不同的授權條款-Apache License 2.0(簡稱 Apache-2.0),Android 作業系統之所以選擇 Apache-2.0,是因為相較於感染力強的 Copyleft 類授權條款,如 GPL,Apache-2.0 相對是對商業公司較有彈性的授權條款,並沒有 GPL 諸多的規定,更不需要將自行開發的程式碼再回饋給開放源碼社群,而可以將這部分程式碼封閉私有化(註一);當然,這樣的論點也受到不少批評,認為這是只享受不付出、佔程式開發者便宜的行為。然而,若是採對使用者規定愈少,愈有利於商業公司軟體開發及利用的論點,只有幾百字規定的 BSD 授權條款豈非最佳選擇?(註二)Apache-2.0 佔有什麼優勢,獲得諸如 Google 等商業公司的青睞,本文以下將與 BSD 授權條款相對照,試著對 Apache-2.0 解析之。

一、著作權授權

Apache-2.0 授與被授權人的著作權相當廣泛,包括了使用、重製、再散布、改作、再授權、公開演播(註三)該軟體及其衍生軟體等,此外,這些著作權許可均具有永久、全球、非專屬、免費、免授權金以及不可撤回的特性,被授權人因此得以安心利用 Apache-2.0 授權的軟體。

與 Apache-2.0 相較之下,BSD 授權條款明示所授與的著作權種類較少,僅有使用、改作及再散布等權利。

二、專利權授權

Apache-2.0 授與被授權人的專利權許可,包含得製造、代工 (have made)、使用、為販賣邀約 (offer for sell)、販售、進口及以其他方式的轉讓 (transfer) 專利授權產品;而這些專利權許可同樣具有永久、全球、非專屬、免費、免授權金、不可撤回的特性。

相較於 Apache-2.0 對專利授權有清楚規定,BSD 授權條款對此則並未有交代。授權條款清楚規定給予專利權授權,能讓使用者在採用該授權軟體上會更加安心。然而,Apache-2.0 對於專利授權也非毫無限制,若一使用者提起專利訴訟,主張該軟體或編寫進該軟體中的貢獻部份(Contribution,註四)構成專利侵害,則依 Apache-2.0 所給予的專利授權自該使用者提起此訴訟那天終止。

三、商標權保留

Apache-2.0 並未授權商標權使用,在其第 6 條規定,除了描述該軟體來源及複製「授權聲明 (NOTICE)」內容時,所合理、慣用性地使用外,不得使用授權人的商號名稱、商標、服務標章或商品名稱等。

前面提到的 Android 作業系統,其商標使用政策為 Apache-2.0 的商標規定作了很好的示範。 Android 商標政策規定,為行銷通訊的目的,任何人皆可以自由地使用、重製及修改 Android 機器人 (Android Robot) 標誌,但須遵照創用CC「姓名標示」授權條款的規定,來表彰授權人/著作人。而關於 “Android” 字樣,Google 則予以保留,並未預先授權使用,除了描述被授權人(使用者)產品時得以使用外,在未取得 Google 同意前不得任意使用該字樣,且使用時需標註「Android 是 Google 公司的商標」等字樣(註五)。

相較於 Apache-2.0 對商標的使用有明確的規定和限制,BSD 授權條款則並未對商標權的使用有所規範。

四、再散布程式時不需提供原始碼

Apache-2.0 規定,當被授權人需符合以下 1~4 項條件時,可以透過任何媒介,以原始碼、甚至目的碼格式,重製及散布該軟體或其衍生軟體(註六):

1. 提供該軟體或衍生軟體的接受者一份 Apache-2.0 條款內容的拷貝;
2. 必須在任何修改過的檔案附上明顯的授權聲明,以說明該被授權人修改了這份檔案;
3. 當以原始碼形式散布衍生軟體,必須在該等衍生軟體中,保留所有著作權、專利權、商標權及署名聲明 (attribution notice),而那些與衍生軟體無關的授權聲明則除外;
4. 如果該軟體散布時,原已夾附「授權聲明」的文字檔 ("NOTICE" text file),則被授權人散布的任何衍生軟體,也必須在該「授權聲明」檔中包含一份易讀的署名聲明。此外,該被授權人亦得在其散布的衍生軟體中添加自己的署名聲明,併入該軟體的「授權聲明」檔中或當作該「授權聲明」檔的附錄。

Apache-2.0 這幾項得再散布程式的條件, 重點在區別程式的原撰寫者及修改者,以及授權聲明的標示,這對商業公司來說是頗重要的,因為修改後程式的品質好壞不定,若產生與原程式混淆的情形,不但無益、還可能有損於公司商譽;另一方面,授權聲明的保留,道理同於「文章歡迎轉載,但需註明出處」,是增值公司商譽的一種方式。

BSD 授權條款對程式的再散布雖不若 Apache-2.0 設有這麼多項的條件,但也非全無限制,BSD 授權條款規定當再散布原始碼,須保留著作權聲明、BSD 授權條款的條件及免責聲明;而當再散布二進位格式的程式碼時,則於散布時須在文件及/或其他資料中複製著作權聲明、BSD 授權條款的條件及免責聲明。

五、修改的程式可選用不同授權條款

Apache-2.0 規定,被授權人可以為其修改的程式、或整體的新衍生軟體,在 Apache-2.0 規定之外添附其他的、或選擇不同於 Apache-2.0 規定的條款;然而,被授權人得這麼做的前提要件是,其對該軟體的使用、重製、及散布皆不得違反 Apache-2.0 的規定。而既然被授權人可選擇不同於 Apache-2.0 的授權條款,私有的授權協議當然是一種選項,因此,包含 Apache-2.0 在內的 BSD 類授權條款的這項特性,是吸引不少商業公司採用的一個重要因素。

六、得提供額外擔保

Apache-2.0 與其他自由軟體授權條款相同,因提供的是無償對授權軟體的使用,因此除了相關法律特別要求,或當事人額外以書面另行約定,否則授權人及任何貢獻者均是以現狀的基礎提供該軟體,未提供任何保證,而是由使用者自行承擔使用該 Apache-2.0 軟體所可能產生的所有風險。

然而,Apache-2.0 進一步規定,當被授權人再散布該軟體或其衍生軟體時,可以選擇提供技術支援、保證或與 Apache-2.0 規定不相違背的其他權利或義務,並對此收費;但是被授權人只能以自己、不能以其他貢獻者的名義為此保證或提供支援服務,且只有當被授權人同意,使每一位貢獻者免於承擔,因其提供技術支援或保證而致的責任或請求時,始得為之。

上述被授權人可提供額外技術支援和保證,可視為提供 Apache-2.0 明示得允許再授權的配套規定,相較之下,BSD 授權條款則僅有典型常見的免責聲明,即授權軟體是以現有狀態提供,未提供任何額外保證的配套方式。

如前所述,同屬 BSD 類的 BSD 授權條款及 Apache-2.0,實有不少相類之處,例如,都不硬性要求再散布程式時需提供原始碼、修改後程式可適用不同的授權條款等,但若細加比較,會發現 BSD 授權條款的用字似乎過於簡略,例如其明示所授權的著作權種類只有使用、改作及再散布,許多授權利用的態樣及授權範圍都未加以規定,也因此衍生許多模糊地帶,例如 BSD 授權條款是否允許再授權,就產生了對授權規定各自解讀不同的爭議;再者,若依照各國著作權法,著作財產權授權約定不明的部分,推定為未授權的預設規定來說,BSD 授權條款規定太過精簡,反而是將使用的風險加諸在採用者身上,這應該也是為何 Google 等商業公司沒有大舉採用 BSD 授權條款的重要原因之一,以避免日後可能產生規範內容不足的風險。相對的,Apache-2.0 則給予了適如其份的補充和說明,並且,一些 BSD 授權條款並未規定、但卻是商業公司關注的重點,如專利權、商標權是否授予被授權人或予以保留,Apache-2.0 都有明文規定。因此,本文以為 Apache-2.0 可以說是 BSD 授權條款「化簡為繁」的呈現,既不會過於精簡、也不至於規定的太過繁複,而是畫龍點睛地在許多重點處加以著墨,若從商業公司多希望其利用自由軟體再加以衍生開發的程式能予以封閉私有化,以及商業公司間交易往來慣有詳細的契約約定等角度來觀察,Apache-2.0 會是不錯的授權條款選擇!

註一:Open Handset Alliance 網站 FAQ 的 “Why did you pick the Apache v2 open source license?” (http://www.openhandsetalliance.com/android_faq.html)(最後瀏覽日:01/07/2012)。

註二:BSD 授權條款最初推出時有四項條款,後廢除須交代於產品中使用了柏克萊加州大學 (University of California, Berkeley) 程式碼的廣告條款,成為三條款的 BSD 授權條款;而三條款的 BSD 授權條款若再刪去禁止使用軟體貢獻者名稱來對衍生產品背書的規定,便成為二條款的 BSD 授權條款
轉寄『第 188 期 PaaS:程式語言開發在雲端「Programming in Paas」(下)』這期電子報

寄信人暱稱  寄信人email
收信人暱稱  收信人email

  • 社群留言
  • 留言報主