[自由文化] 什麼是「開放資料」？2011-12-29 09:10 作者是 OpenData／TW 徐子涵 文摘 這裡搜錄了一些關於開放資料的好文章，歡迎閱讀。 英國：Open Data 正要跨越鴻溝 http://citypatterns.blogspot.com/2011/08/open-data.html 邁向數位民主時代：Open Data旋風推動青年公共 http://www.erenlai.com/index.php?option=com_content&view=article&id=4453 Open Data: Open What? What Data? http://citypatterns.blogspot.com/2011/08/open-data-open-what-what-data.html Open Data/開放資料：台北市選舉投開票所 http://charlesc.ilovemeow.net/blog/20101122/1174 公部門資訊與行動軟體 http://zonble.net/archives/2010_11/1436.php 中文維基百科－Open Data http://zh.wikipedia.org/wiki/Open_Data 網際網路發明者 Tim Berners-Lee 談 open data http://gis.rchss.sinica.edu.tw/qgis/?p=942 第一次玩語意網 Semantic Web 與開放資料 Open Data 就上手 http://talk.ernestchiang.com/2010/08/semantic-web-open-data.html 資料開放力—Open Data http://newideas.cc/magazine/article.php?AKEY=1746 當一切都成為網路-資訊公開與資料近用 http://d-academy.tw/archives/1788 墨西哥開放資料運動進展 http://leonardwrites.wordpress.com/2011/08/25/墨西哥開放資料運動進展/ 創用授權和開放資料 http://citypatterns.blogspot.com/2011/08/blog-post_08.html 紐西蘭政府推動開放資料政策 http://creativecommons.tw/blog/20091001 群眾外包到資料民主化探討公民參與 http://novxnisme.blogspot.com/2011/10/blog-post.html Open Data 介紹影片 我繳給政府的錢到哪去了？到底每天什麼時候會來收垃圾？原來，「Open Data」和這些都有關係？！在英國 OKFN （開放知識基金會）所製作的這部段影片裡，我們將會跟著 Open Data 領域的專家們，透過一些有趣的例子共同分享： 什麼是「開放政府資料」？ 讓世界更好的三種方式！ 開放資料有什麼好處？ 如何 Open Data? Open Data 的三個目標。 在一個資訊社會中，資訊是世界上主要的基礎建設。我們相信，彙集眾人的力量 Open Data，我們將擁有改變社會運作的能力！ #opendata from Open Knowledge Foundation on Vimeo. 繁體中文版字幕翻譯，感謝 HuiLin Huang (Youth Synergy Taiwan Foundation) Yuwei Lin （林鈺維） University of Salford, UK, (Personal website) Chang Weitze (Whisky) (Youth Synergy Taiwan Foundation Jessie Lin (Youth Synergy Taiwan Foundation) 法國的 Open Data 介紹短片 [自由專欄] 電子書包在臺灣：產品掛帥，專業無奈2012-01-03 09:41 作者是 洪朝貴 ◎ 本篇文章傳達作者意見，不代表自由軟體鑄造場電子報立場，回覆意見請見部落格原文網址，採用 CC-BY-SA 授權 摘要 「只談優點，不談缺點」，在臺灣，主導（傳統、筆記、平板）電腦輔助教學的力量來自電子資訊產業，而不是來自教學專業。在這一波電子書包狂熱中，專業意見再度缺席，將造成「科技提升教學效果」的機會再次流失，與國家龐大教育資源的浪費。 一、微積分教師所需要的數位平等電子書包 ▲ sin 函數的定議，從割線到切線 數學、物理、化學的教學很適合互動學習。不論是理化的實驗，或是操作橢圓規動手體驗幾何定義， 往往比黑板上的抽象符號更能讓親手操作的學生「感受」到抽象的數理概念。今日的電腦，提供了過去教師所沒有、甚至無法想像的教育機會。筆者曾在電腦教室上過一學期的微積分課，部分主題使用電腦輔助教學，包含： 複習拋物線的幾何定義與代數定義（使用 drgeo 與 gnuplot） 複習三角函數的定義（使用 drgeo 與 gnuplot） 極限與連續/不連續的定義（使用 gnuplot） 曲線的割線與切線（使用 drgeo） 徒手繪製（不需要認識的）複雜函數的導函數（並用 gnuplot 驗證） 徒手繪製（不需要認識的）複雜函數的積分（並用 gnuplot 驗證） 分部積分的應用（使用 maxima 驗算） 二次連續與二重連續（使用 gnuplot） 從一位數學專業教師的角度來看，不論是誰出錢，如果要配發電子書包給學生，這個電子書包應該至少包含： drgeo，或是 geogebra，或是 kig 幾何互動軟體 gnuplot 函數繪圖軟體 maxima 代數符號運算軟體 自由授權的中英文微積分講義 以最低的硬體需求來說，一片稍加修改的 ezgo DVD，或一顆安裝 slax 的 2G 可開機隨身碟，再搭配零管理的無硬碟電腦，就可以滿足這樣的需求。當然，國高中數學老師的需求與微積分課程不盡相同；但不論是哪個年級的數學課程，只需上述基礎配備再搭配其他數學教學自由軟體，就可以創造出電腦時代來臨前不敢夢想的教學效果。 ▲ 聖喬瑟夫 St.Joseph's Convent School 數理教師驚艷 drgeo 與 ghemical 而且這些技術早已不稀奇新穎。筆者早在 2003 年開始介紹 drgeo 的數學教育應用、gnuplot 的應用介紹則更早。但很遺憾的是：經過十多年，這一類的科技輔助教學產品似乎一直不受數學教育界重視。這並不是僅有數學一個學科才會受益的技術，而是一整個「已有成功示範、有待推廣散布」的廣大領域。這類技術偶爾會見於自由軟體相關研討會，但畢竟研討會的目標通常是提出新穎的議題而不是促成既有創新的普及。然而使用數位平等的資訊科技融入教學，最大的挑戰向來就是擴散而不是創新。從 Everett Rogers「創新的擴散」一書的角度看來，「observability」──數理教師對於創新成效的體會──可以是一個提升擴散效果的施力點。依照筆者自身的經驗，只需要半小時到兩小時的時間，數理教師就可以感受到此類教學的優越。可惜在我國似乎不曾見過任何縣市大規模舉辦此類教師研習，更不用說後續相關教材教案的開發與推廣。於是，我國多數的數理教師對於「資訊融入學科教學」的想像始終停留在單向播放 Powerpoint 或 flash 動畫；只有少數教師有機會透過部落格、噗浪等網路資源及研討會，體認到學生動手操作的可能性與效果。而在高層選擇電子書包的決策過程當中，專業教師反應此一需求的聲音也就不會出現。 二、教學互動功能貧乏、行銷聲勢浩大的科技產品 另一方面，校園內彌漫著產品掛帥、商品主導教學的氣氛。以強大商業力量為後盾的實體商品在未經教學專業人士公開評估討論的情形下，就透過媒體及行政力量以排山倒海之勢攻佔校園；而教師們也因為新鮮感、實體具象而對這些產品有熱烈的反應。蘋果電腦的 iPad 就是一個最明顯的例子。 撇開言論管制的爭議，單純從休閒娛樂消費性電子產品的角度來看，iPad 的確是一項操作介面高度友善的產品，很適合作為一種被動閱聽的休閒工具，例如讓無意深究科技的年長者上網閱覽及欣賞音樂影片等等。此外，以被動閱聽者的單純需求來看，在蘋果電腦 iPad 政策下禁止解譯器之類的應用軟體確實可以降低病毒及木馬程式入侵的機會。 但從互動學習的角度來看，嚴格控管的環境也扼殺了許多可能性。互動科學教學網站 PhET 的常問問題集當中回答這個問題：「PhET 可以在平板電腦、iPad、Android 裝置上執行嗎？」 目前平板電腦、iPad、Android 裝置無法完整支援 Java 或 Flash，而 PhET 需要這兩者。 iPad 不支援 Java 和 Flash，所以完全無法執行 PhET。 Android 對 Java 的支援太差，所以 PhET 完全無法使用 Java 所撰寫的模擬；至於用 Flash 所撰寫的模擬，Android 裝置可以支援一部分，但效果很差。 要讓這些裝置執行 PhET，補足平臺與環境不是唯一需要克服的問題。就算用別的程式語言重寫 PhET 也無法解決問題，因為PhET 的設計假設操作的介面是滑鼠與鍵盤。有些事情用觸控螢幕來做就是不順手，例如「按右鍵」和打字，尤其是虛擬鍵盤會蓋到畫面的時候；而有些事則是完全不可行，例如滑鼠移動到物件上方。 如果貴學區正在考慮購買 iPad 或平板電腦，請注意 PhET 的模擬會大打折扣甚至完全失效。我們推薦解析度至少 1024x768 的筆電或小筆電。詳見系統需求。 另一個深具教育意義、由 MIT 所開發，並且在每童一機 (OLPC) 計畫當中扮演重要角色的互動學習環境 Scratch，也被排拒在 iPad 門外： 非常遺憾蘋果電腦依據其禁止解譯或執行程式碼應用軟體的政策，決定不允許 iPhone 或 iPad 執行 Scratch。在我們看來，最重要的事情莫過於鼓勵兒童用新形式的媒體設計、創作以表達自我，這正是 Scratch 背後的理念。全世界的孩子們用 Scratch 設計他們的互動故事、遊戲、動畫、模擬器，並在線上分享他們的作品。在這個過程中孩子們學會創意思考、系統性推論和合作。 Android 並沒有蘋果電腦的「禁止解譯器」政策，而且確實已有成功在 Android 上執行 Scratch 的報告，所以比 iPad 更適合用於需要互動的教育環境。不過話說回來，既然筆記型電腦沒有「欠缺滑鼠」的問題，且早已完整支援 PhET、Scratch 以及 drgeo、gnuplot、maxima、stellarium、ghemical……等其他眾多教育軟體，那麼我們堅持捨筆電而就平板的理由又是什麼呢？遺憾的是，面對這波平板狂熱，過去追隨微軟、強勢主導國家政策的 PC 產業節節挫敗，現在似乎又不懂得善用學科教師的專業意見來推廣自家產品。 三、教育不敵利益 國家政策研究基金會的趙麗雲委員在「電子書包上路，新教學與學習體系亟須建置」一文中提到： 根據國外研究機構報告指出，至 2013 年前全球電子書的複合成長率將達到 124%，其產值將超過 25 億美元。另據推估，國內電子書產業鏈去年（97 年）產值為 120 億元，在行政院擬訂電子書產業行動方案的推波之下，其產值可望在 2013 年達到一千億元。 Zdnet 的意見則更直接露骨。他在標題為「電子書包促進會成立，推動數位化學習 500 億商機」的文章中提到： 台北市電腦公會、國科會、教育界及掌上型裝置軟硬體製造商等產官學界人士今日組成電子書包促進會，以更具規模及組織的行動促使我國中小學電子書包普及。……根據電子書包促進會表示，依據台灣國小到高中 380 萬學生，每人一萬元的費用，以及 3600 所實施學校的無線網路佈建，共 90 億，加上其他費用，估計約有 500 億的產值。 於是在不曾公開徵詢專業教師意見的情況下，臺北市決定推廣電子書包並設計專屬教案： > 教育局表示，100 學年度提供給市內 16 所國中小，每校 70 台，共 1120 台的平板電腦，均由國內業者提供，每台單價約 1 萬元，所有費用均由經濟部工業局埋單。101 年學年度推廣至 30 校、102 年 50 校、103 年再加 70 所學校。明年起，所需費用都由市府支付，學生或家長不用出半毛錢。 當然，文中沒有提到的是：哪些專業人士參與推薦這樣的電子書包推廣專案？是第一線的專業教師？還是視國家教育資源為提款機的利益團體？文中也忘記陳述一個簡單的事實：經濟部工業局的經費來自納稅人──全國的納稅人，而非僅有臺北市的納稅人。於是在各縣市不願吃虧的本位主義氣氛之下，後續的輿論呼聲將是電子產業利益團體的最佳推銷員，全國納稅人於是集體將國家教育資源送入利益團體手中，為全國每一位學童換來不一定能夠發揮教育效果的新穎玩具。 身兼一位大學數學教師和家長，如果學生必須購買電子書包，我所樂見的，是這些電子書包能支援教學效果良好的互動式幾何與代數教學軟體（drgeo、gnuplot、maxima 等等），或是互動式創作工具（例如 PhET 與 Scratch）；而非學生家長被迫嘉惠國家電子產業。 「以平板電腦作為電子書包」一事，對臺灣社會的意義僅止於師生家長得到新玩具、縣市長增添政績及電子產業增加產值。至於數、理、化、等學科的教育專業看法，卻連在教育界裡也悄然不聞。在臺灣，主導電腦輔助教學、電子書包導入校園的聲音，既不是來自 MIT 的遠見，也不是來自基層學科教師的需求，而是來自「把教育市場視為大餅」的電子產業，以及政治體系中的推銷員。但是，當我們集體決定捨棄「比較符合數位平等與教學需求」的技術，改用「即將擴大城鄉數位落差且不符教學需求」的技術時，國家教育資源所滋養的對象到底是求知的學童，還是求利潤的電子產業？我們，真的是一個在乎教育的民族嗎？ 四、結論：誰能阻止反客為主？ MIT 每童一機計畫主持人 Nicholas Negroponte 教授談論今日主流資訊教育淪為辦公室套裝軟體 (Office) 訓練班時，大膽道出許多教師不敢說出口的質疑： 我認為那（教學生使用 Office）根本就是一種罪行──小孩子應該做的事情是創作、溝通、探索、分享，不是操作辦公室自動化工具。 至少從十多年前開始，商業利益就透過政治力量主導科技教育，而一般民眾及教育界卻渾然不覺，甚至透過輿論及教育機構系統性地協助炒作。它所造成的負面影響極為深遠，直到多年後的今天，我們仍舊很難走出這個框框。那麼現在如果我們再次盲目地、拒絕思考地追隨商業炒作，未來又將剝奪下一代多少真實的教育機會？ 這種「產品行銷主導政策、原始公共議題失焦」的現象，在其他產業也層出不窮。比爾與美琳達蓋茲基金會僱用 Trevor Mundel 擔任基金會全球健康計畫總裁。Mundel 現任職於瑞士藥廠 Novartis Pharma 開發部門國際主席。Novartis 藥廠的作為近年來在印度引起許多爭議，最近一次的事件是 Novartis 企圖以「永遠的專利」(evergreening) 手法阻止廉價的普通藥品上市。Techdirt 網站評論： 今日醫療健保問題主要爭議之一是：藥品議題取代健康議題成為鎂光燈的焦點。沒錯，藥品是健康問題的環節之一，但並非全部。遺憾的是許多決策者讓藥廠來主導辯論；而過去一長串的事件顯示，藥廠關心的並不是大眾的健康，而是他們自己的利益。藥廠爭取自己的利益並沒有錯；我的問題是：為什麼讓他們主導公共政策，甚至讓他們用不公平及可疑的手段爭取利益，以至於社會大眾無法取得（或無法以合理價格取得）藥品？ 本文和 Techdirt 一樣，我們所主張的並不是反對商業利益，而是商業利益不應該反客為主，不應該將整個社會的教育思考誘入精美華麗的牢籠，就如同藥廠不應該將整個社會的健保思考導入藥到病除的想像。電子書包與電腦輔助教學，應該從教育專業人士的真實需求出發；政策的形成，應該經過公開透明的討論。由教育專業人士參與公開討論；找到真正有助於提升學童創作、思考、理解、合作能力，真正最符合成本效益的方案。然後再由──理想上是「於本地設廠且僱用本地員工的國內自有品牌」的──電子產業配合教育專業的需求，量產真正有助於教學現場的廉價方案，順便在過程中創造確實屬於我國產業自身的產值。這才是真正有利於社會整體的政策。至於我們的學科專業教師也需要更積極地發聲，促成縣市政府教育局舉辦「教學為主，科技為輔」的學科教師研習，並善用既有的數位平等軟體工具開發教材與教案（例如 drgeo 的互動圖案），讓早就存在的創新有機會真正地擴散。 本文延續「科技融入教育：產值觀點或教育觀點？」一文，將在「創新教育與自由軟體校園應用」研討會當中發表。 [法律專欄] 化簡為繁的 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 授權條款。因三條款 BSD 授權條款與 Apache-2.0 在架構上較為接近，所以本文取三條款 BSD 授權條款來與 Apache-2.0 相以對照比較，本文中「BSD 授權條款」特指三條款 BSD 授權條款。 註三：本文作者以為 Apache-2.0 第 2 條著作權的授權，並不若其表面字義只包含「公開展示 (publicly display)」及「公開演出 (publicly perform)」，而是類似創用CC 授權條款 3.0 台灣版的中譯，使「公開演播」一詞廣義地含括但不限於我國著作權法所定義的「公開展示」、「公開演出」、「公開上映」、「公開播送」、「公開傳輸」及「公開口述」等權利；然而，需注意的是，ASF 雖對 Apache 授權條款的翻譯持開放態度，但亦言明各國的翻譯版本並不具法律拘束力，仍須以英文版本的 Apache 授權條款為準，請參 ASF 網站 “Apache License and Distribution FAQ” (http://www.apache.org/foundation/licence-FAQ.html) 的 “May I translate the Apache license into my local language for my redistribution of Apache packages?” 的說明（最後瀏覽日：01/07/2012）。 註四：在本文的脈絡之下，Apache-2.0 的 “Contribution” 是指為了要被納入到該軟體中，而被合法遞交給該軟體著作權人的任何內容，這些內容可以是該軟體的原始版本，以及針對原始版本或衍生軟體的任何改作或新增，詳參 Apache-2.0 第 1 條定義條款 (Definitions)，http://www.apache.org/licenses/LICENSE-2.0.html（最後瀏覽日：01/07/2012）。 註五：http://www.android.com/branding.html（最後瀏覽日：01/07/2012）。 註六：Apache-2.0 的 “Derivative Work” 是指，不論是原始碼或目的碼格式，基於該軟體而衍生的軟體，例如，編輯上的修改、註解、優化、或其他修改行為，而整體展現與該軟體同樣的創作內涵；然而，基於 Apache-2.0 的編撰目的，衍生軟體不應包含與該軟體或其衍生軟體運作獨立、或僅連結至該軟體或其衍生軟體介面的其他軟體，詳參 Apache-2.0 第 1 條定義條款 (Definitions)，http://www.apache.org/licenses/LICENSE-2.0.html（最後瀏覽日：01/07/2012）。[企業應用] 透過 oDesk 建立虛擬團隊2012-01-10 09:42 作者是 marr 這年頭，資訊服務上了雲端，我們也能在雲端建立虛擬的軟體開發團隊嗎? 如何運用既有的線上服務管理虛擬團隊呢? 本文將介紹 oDesk 平台服務，以一個開放源碼為基礎的專案當作例子，說明 oDesk 的操作方式，並透過雇主 (employer) 和雇員 (contractor) 兩種角色，介紹專案執行流程裡要注意的事項。 委外開發的種類很多，除了軟體案之外，還包括設計或行銷案等，本文打算只聚焦在個人經驗的分享，也就是以網站應用軟體的開發為例。 委外開發的動機 在台灣，高素質的軟體人員仍然不足，撇開有意自行創業的個體戶不提，純軟體公司很可能要跟硬體公司搶人，或是考慮召募年輕程式員，以培養經驗和革命情感，正因為 in-house 的成本和變數都難以降低，造成 outsoruce 經常成為軟體開發的評估選項之一。但是，這並不意味委外開發是條更經鬆的途徑，相反地，它的實質門檻更高，為了降低與管理這些門檻，委外開發的管理平台應運而生。 台灣既有的委外平台，常見以「外包網」為名稱，並強調「可以降低企業成本，彈性補足公司資源，讓時間急迫的專案變成可能」，可惜的是，這些訴求的出發點，都是造成委外開發市場惡性循環的原因。另一方面，外包網經常一案多報，造就案量豐富的假象，並要求客戶要先付費成為會員，才能看到更多案源，這不僅讓人難以信服，如果付費後還是沒有優質案源，本質就是變相詐欺。最後，軟體開發的報價還算有憑有據，設計領域的行情顯得更混亂，合理的鑑價機制，成為改善委外產業的重要議題。 國外的委外開發管理平台，不僅規模可觀，有些還致力促成市場良性循環，像 oDesk 就是知名平台之一，它的使用族群以程式員為大宗，廣受 soho 族喜愛，成功將「才能」轉換為「勞動力」，據說公司有潛力在近期內達到具備上市條件。 oDesk 的特色 「Hour Worked is Hour Billed/Paid.」是 oDesk 努力的口號之一，也就是說，雇主和雇員都滿意之後，oDesk 才會對雙方收取費用，在此之前，雇主和雇員同樣享有免費註冊、免費查詢、免費應徵的權利。平台的收費方式分成「時薪」和「固定費用」兩種，預設鼓勵使用時薪方式，雇主和雇員還可以提議新的時薪額度，做為商討的依據。 完成工作後，雇主要在一週之內完成驗收，請特別留意，oDesk 提供爭議調處 (dispute) 機制，不過，僅限於採時薪制的案子，因此，新手優先選用時薪付款方式，容易獲得更多保障。 註冊平台時，需要事先決定角色，主要就是分成「雇主」或「雇員」，也就是買方或賣方，如圖1所示。除了操作網站之外，還可以下載 desktop 或 mobile app 軟體，協助管理專案，詳細的報表和評比工具，都是媒合買賣雙方的好幫手。 ▲ 圖1 註冊過程需要選擇角色 oDesk 對買賣雙方提供驗證或評比機制，例如既有合約的滿意度評分記錄，雇主是否完成付款方式的登記，雇員是否完成英文或程式語言的測驗，既有工時或合約款項的總額，這些公開資訊都有助於買賣雙方，進行基本的面試篩選。 張貼工作的流程 讓我們先以雇主身份認識張貼工作的步驟，首先要完成圖2所示的註冊表單內容。 ▲ 圖2 雇主身份的註冊表單 雇主的操作介面分成「Recruit」「Manage My Team」「Wallet」三大項，在 Recruit 裡點選「Post a Job」按鈕，填寫 Job 表單，就可以新增工作內容，如圖3所示。 ▲ 圖3 Job 說明表單 工作內容應力求明確，通常要包括開發環境及版本要求、技能要求、時限、示範畫面，如果編輯介面只能使用文字的話，可考慮另貼圖片網址，如圖4所示。 ▲ 圖4 Job 範例文字 雇主可以指定一週工時上限，雇員超過工時上限的話，並不會加收費用，如圖5所示。 ▲ 圖5 指定一週工時上限 進階選項包括「英文流利程度的要求」，oDesk 提供多種測試，協助驗證雇員的各項能力程度，這些並不是強迫要求的選項，卻提供買賣雙方一個更具體的評估依據。 應徵工作的流程 雇員的註冊流程和雇主類似，差別在於個人履歷選項更多，如圖6所示。 ▲ 圖6 Profile 檢查列表 需要填寫的內容包括電子信箱、聯絡資訊、專長領域、每週工時等，其中的預設時薪是重要資訊之一，以 25美金為例，oDesk 會收取 10%的費用，因此雇主實際上要付 27.78美金。另外，剛加入平台時，每週最多能應徵兩個工作。參考圖7畫面。 http://www.openfoundry.org/images/120117/oDesk/07-account-summary.png ▲ 圖7 預設時薪和每週應徵數量上限 雇員的操作介面分成「Find Work」「My Jobs」「Wallet」三大項，查詢工作時可以使用關鍵字，也可以新增時間、專長等過濾條件，如圖8所示。 ▲ 圖8 Job 查詢畫面 應徵工作時，必須決定提議的時薪金額，系統會自動計算雇主的付款總額，填上 Cover Letter 內容，確認同意條款就能寄出應徵信，如圖9所示。 ▲ 圖9 Job 應徵表單 雇員的應徵狀況清單分成三類，第一類是剛送出的應徵信，第二類是雇主有回應的討論信，第三類是雇主個別寄來的面試邀請信，如圖10所示。 ▲ 圖10 雇員的應徵狀況清單 面試的流程 雇主除了等待潛在雇員來應徵外，也可以主動發出面試邀請信，雇主的應徵狀況清單分成兩類，第一類是尚未回覆的應徵名單，第二類是有回應的討論信，如圖11所示。 ▲ 圖11 雇主的應徵狀況清單 遇到合適人選應徵時，第一件事當然是寫信回應，如果雇主覺得報價太高，可以主動提議新的時薪，如圖12所示。 ▲ 圖12 雇主提議更改時薪 配合上述情況，應徵者會收到時薪更新的提議，同意的話，可以按下「Accept this Job」按鈕，如圖13所示。 ▲ 圖13 應徵者的新時薪提議畫面 確認合約後，買賣雙方會看到合約編號、生效日期、時薪金額、一週工時上限等資訊，如圖14所示。 ▲ 圖14 合約生效畫面 雇主會看到團隊成員的管理畫面，包括成員列表、每週累計工時、最近工作標題摘要、所在城市及時區，如圖15所示。 ▲ 圖15 成員管理畫面 軟體工具的使用 想要事半功倍的話，可以到 https://www.odesk.com/downloads 下載 oDesk Team 工具軟體，目前有 Desktop 和 iPhone App 版本，如圖16所示。 ▲ 圖16 oDesk Team 下載網頁 oDesk Team 類似即時通訊軟體，可以查看團隊成員的狀態，包括視訊功能的支援，如圖17所示。 ▲ 圖17 oDesk Team Room 畫面 也可以用來線上討論工作，如圖18所示。 ▲ 圖18 oDesk Team 線上討論畫面 oDesk Team 的特色是可以用來自動記錄工時，點選 Time tracking 的「Start」按鈕，代表雇員進入記時工作模式，系統每隔數分鐘會抓取桌面畫面，並記錄期間內，點按鍵盤和滑鼠的次數，雇員可以輸入 memo 記錄目前的工作摘要，如圖19所示。 ▲ 圖19 oDesk Team 記時工作模式 上述的桌面記錄，會自動傳送到 oDesk 網站，成為 Work Diary 的內容。Work Diary 採取月曆形式顯示工時，搭配 oDesk Team 軟體的話，工時會分成 auto-tracked 和 manual 兩種，auto-tracked 時段以綠底標題顯示，manual 時段以黃底標題顯示，兩者加總之後，就是記錄的總工時，如圖20所示。 ▲ 圖20 Work Diary 初始畫面 Work Diary 提供方格或條列兩種顯示方式，在方格顯示方式下，可以瀏覽記錄的桌面畫面，如圖21所示。 ▲ 圖21 Work Diary 方格顯示方式 付款結案的流程 雇員完成工作後，系統會通知雇主查看 Work Diary，確認成果符合需求，一切無誤的話，預設在一個星期內，oDesk 會提供 Timelogs 報表，說明工時狀況和待付款項，如圖22所示。 ▲ 圖22 Timelogs 畫面 雇主如果想要提供額外獎金的話，可以點選「Give Bonus」來付款，如圖23所示。 ▲ 圖23 Give Bonus 畫面 已經排定的付款項目，稱為 Pending Transaction，會在到期日 (Due Date) 從信用卡扣款，如圖24所示。 ▲ 圖24 Pending Transactions 畫面 完整的付款記錄，會以 Transaction History 報表顯示，如圖24所示。 ▲ 圖25 Transaction History 畫面 合約履行階段發生爭議的話，買賣雙方最好事先達成共識，例如雇員同意未達雇主要求，可以在 Contract 畫面，點選「Give refund」主動退選款項，如圖26所示。 ▲ 圖26 Give refund 畫面 雇員填寫要退還的金額和說明文字，點選「Give Refund」按鈕就行，如圖27所示。 ▲ 圖27 決定退款的畫面 合約順利完成，或是雇主更換雇員的話，都可以點選「End Contract」來結束合約，系統會詢問結束理由，買賣雙方對彼此的評價，以五星等級來評分，如圖28所示。 ▲ 圖28 合約結束的問卷畫面 小結 在 https://www.odesk.com/oconomy/ 網址會定期公佈 oDesk 的統計資訊，以 2011 年 11 月為例，成交金額達兩千三百萬美金，平均一個案子金額是四千美金，規模最大的成交金額來自網站應用程式開發，其次是軟體開發。成交數量最多的時薪金額，大約在 30 美金，印度、菲律賓、東歐，依序是提供人力資源的最大宗，美國則是最大的需求國家。 oDesk 目前提供近 344 項技能測驗，分成三十類，包括語文、程式語言、網路技術、軟硬體知識、資料庫等，每項測驗通常會有亂數產生四十個複選題，要在四十分鐘內完成，相隔三十天才能重新參加測驗，測驗通過率大約五成，如圖29所示。 ▲ 圖29 技能測驗畫面 新手雇主初期的最大挑戰，在於「如何得知哪位應徵者才是能力最強，或是哪些人能力夠強」，通常要磨合互動後才能知道，難有捷徑，無法速成。找到具備默契的雇員之前，要求「密集快速互動」是很重要的步驟，雇員如果能夠先回覆部份的程式碼，不但能夠先檢查 coding style，也會避免「要 Python 給 PHP」的尷尬場面。 工作期間除了要以英文做為溝通語言，程式模組最好也符合 i18n 架構基礎，讓雇員能在英文介面進行開發，雇主事後則自行完成 l10n 調整，或是再將 l10n 工作另行委外。另外，也值得考慮使用 SCM 工具管理程式碼。透過軟體工具提昇虛擬團隊的工作效率，是 oDesk 這類平台的未來發展方向，既有的模式之一，是透過看板 (Kanban) 管理，讓工作成果和瓶頸能被即時展現。 就個人在 oDesk 委外網站應用程式開發工作的經驗而言，既有工作環境以 Plone 為基礎，合作滿意的雇員，都是 Plone 社群的資深程式員，社群資歷這項因素，對於以開放源碼為基礎的專案來說，應是高信度的人才篩選條件。相信這類平台工具所代表的商業模式，未來將對委外開發市場帶來巨變，演化中的程式員勞動交易方式，正在形塑知識工作者的前緣疆域。 [技術專欄] 利用 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 大封包測試。 詳全文[技術專欄] Heroku──Ruby 程式語言的最佳雲端環境2012-01-06 09:00 作者是 高見龍 (Eddie) 您曾經用 Ruby on Rails 開發網站，但在國內找不到可以用的主機空間嗎？或者您是新創公司，但初期還沒有足夠的資金投資伺服器的硬體設備嗎？又或是沒有專職的 MIS 幫您管理伺服器？讓我們來看看 Heroku 吧！ 詳全文[技術專欄] 與 PHP Fog 的第一次親密接觸 - OpenFoundry2012-01-04 14:22 作者是 [NISRA] Loyo, Snake／文；[NISRA] Allen Own／技術指導 前言 相信許多人都有開發 PHP 的相關經驗，豐富的資源及其便利性皆為不可忽視的優點，程式本身撰寫起來也相對容易，相較之下環境建置及部署反而成為許多開發者的困擾。PHP Fog 透過 PaaS 的方式減輕了開發者在這方面的負擔，透過幾個簡單的步驟便將開發時所需的環境及資料庫設定完成，並且提供許多 Framework 可直接選用，讓開發者能更專注於程式開發。以下將透過 PHP Fog 平台簡易實做 PHP 程式開發。 詳全文[技術專欄] Python/Django on Heroku2012-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 歲之間。 從以下數據可以得知，電子報讀者以從事資訊軟體的人為最多，其次是學校或其他非營利性質之研究機構，再來是資訊硬體業。另外，在興趣與專長方面，Programmer/程式設計、MIS/網管系統管理、軟體開發依序位居前三名。 從第 8 題的調查結果來看，我們可以觀察出讀者的使用習慣，大部份人都是訂閱電子報 Web 版，再連結到 OpenFoundry 主網站閱讀文章。另外，值得一提的是 OpenFoundry Facebook 非官方粉絲團是去年八月才成立的，但使用臉書來 follow 本電子報文章的人也有一定比例。 第 12 題的結果也呼應到前面第 5 題的讀者所在領域和讀者興趣/專長。有 50% 的讀者最常點擊技術專欄文章，這個發現也跟本電子報的經營方向一致，一直以來我們都以技術專欄為主推，從去年十一月開始則不定期的推出技術專題系列，使技術文章更有系統性的呈現。 從第 13 題可以得知，有 59.9% 的人認為本報技術專欄是最令人滿意的專欄，再來很明顯得可以看出介紹軟體應用的源碼秘技位居第二。就第 14 題而言，最多人認為企業應用(企業採用策略探討)這分類有待改進。本電子報確實在企業應用方面題材的文章，其數量上較為缺乏，在未來的一年裡，我們也會盡力去經營、認識相關方面的人脈，邀請他們撰寫相關專文，以符合讀者需求。 根據第 16 題的數據，選擇 [符合] 與 [非常符合] 的讀者比例大約佔 57%，表示有超過半數的讀者都認為本電子報很符合他們心中的期待。雖然如此，電子報編輯們仍覺得選擇 [尚可] 選項的讀者的意見非常的重要，這會是讓我們更進步的動力，因此接下來，我們會針對第 17 題讀者給的寶貴建議做回應。 讀者建議： 有讀者表示，技術專欄缺乏次分類，不方便讀者進一步閱讀其他相關文章。 → 針對這點，電子報編輯們也已經在著手規劃次分類具體的作法。本電子報是以技術為主的刊物，從自由軟體鑄造場計劃成立之初累積至現在，技術文章的資源已經相當豐富且數量可觀，增加次分類的規劃不僅可以對於讀者的便利性大大提升，更可以讓這些珍貴的資源有效地被再次利用。感謝讀者具有建設性的建議！ → 有讀者指出，希望技術文章可以多介紹一些在非 Linux 環境下也能使用的跨平台的技術，讓在不同環境下的人都可以使用電子報中介紹的 OpenSource 工具。 → 關於讀者的這個需求，我們會勤加改善。考量到實際情形，確實有很多人是使用非 Linux 環境，但也想使用 OpenSource 工具。未來電子報將會提供更多元的內容，以符合各種不同平台讀者的需求。感謝讀者的不吝賜教！[源碼快訊] 自由軟體校園演講 Call for Presentations2012-01-16 14:52 作者是 林珈宏 自由軟體鑄造場校園演講徵求講者，歡迎有志至大專院校分享開發心得、從事自由軟體教學、推廣自由軟體的朋友們，能加入校園推廣演講的行列，將您的知識、理念及熱情貢獻給學校師生！ 詳細說明 作為自由軟體校園演講的媒合平台，OSSF 會將相關的講題、大綱等資訊提供給學校師生（參見此頁面），讓師生選擇與課程教學有相關的若干講題，再由 OSSF 與講師連繫，就演講日期、地點及相關事項進行討論；討論出結果後，OSSF 即向提出申請的師生確認該場演講。演講日，OSSF 校園推廣負責人也會與講師一同前往出席，讓講師可專心準備演講內容。 聯絡方式 如果您有意願擔任校園演講的講師，可依下列方式回覆： 回覆格式 講師姓名： 講師簡介： 講　　題： 議程大綱： 議程時間： 參考資料： 聽講對象： 簡報授權方式： 是否同意錄影： 錄影授權方式： 其他需求： 回覆說明 講師簡介一欄，若講師願意留下聯絡方式或社群帳號，也將置於此處。 可提供多個講題；每一講題須搭配一個議程大綱。 參考資料一欄，可放置若干網頁連結，供聽講者預先閱讀學習；若無，亦可不填。 聽講對象一欄，可標明本議程適合資工系（資管系）幾年級以上、碩士班學生，或是已上過哪些課程的同學來聽講，讓聽講對象更能有效學習；若講師將以申請對象客製化演講內容，亦可不填。 您的簡報將置於 OSSF 校園演講頁面供公眾下載，故請選擇您欲採之公眾授權方式；若您對於公眾授權方式不甚了解，請洽 OSSF 校園推廣負責人。 建議您以開放格式釋出您的簡報。 若您同意錄影，您演講之錄影檔將置於 YouTube 供公眾觀看，並請選擇您欲採之公眾授權方式。 其他需求一欄，可自由填寫任何您對於 OSSF 安排校園推廣的相關期待及想法。 來信 ossfschool AT openfoundry.org 來信標題：自由軟體校園演講 Call for Presentations - (您的名字或 ID) 來電 02-2788-3799 ext. 1477 校園推廣負責人 林珈宏 (Richard) 關於自由軟體校園演講 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-09 09:32 作者是 OpenData／TW 徐子涵 我那場運氣不錯，排在第一天的上午，雖然環境很不適合（相當嘈雜）而且非常混亂（有 SXSW 的實戰感覺），但幾乎是全室爆滿，談的就是莫拉克風災的經驗。我把層次再拉高一點到 open data 的「天堂」只會在災難時出現的這個點。因為泰國最近大洪水，所以聽眾很快就抓到我想表達的點。講開放資料的這些團體跟災難防救的那一群有點距離（例如 CrisisMap, Ushahidi），所以我就利用台灣的例子，嘗試把兩個串起來。 由於「莫拉克」的案例實在太特別，所以十分多鐘講完後，陸續有南非、荷蘭、英國、盧森堡、德國、法國、摩爾多瓦和羅馬尼亞的人來攀談並且詢問諸多細節。相當大的比例認為這經驗應該多說一點，所以我答應了 http://www.ejc.net/ 的一位計畫協調人，近日會寫一篇比較長的文章給她，讓這經驗透過歐盟新聞傳播學院的體系再發散一次。 這次順便把青平台基金會和 opendata.tw 廣為「佈達」。不過類似的基金會和計畫在開放資料的領域不在少數，台灣各個城市的體質以及 ICT 環境有這個機會，但目前狀況仍然沒有什麼值得提的。不過至少已經讓歐洲這幾個單位有個印象，了解台灣有組織、計畫和人在弄這個東西，也算是欣慰。 直接進入主題。通常無聊的「國際會議感想」除了躺在陳年的出差舊卷宗裡，就再也不見天日，但我等諸君既然務求開放資料的精神，當然也要把 open data 的精神落實到實務上。此揭一系列就是落實的果蒂。 本次營隊 (camp) 主要由 Open Knowledge Foundation 所舉辦。但這營隊跟台灣平常所識之「營隊」有相當差距。「營隊」型態之活動所指涉為活動籌組以及活動的進行方式，跟參與成員是否德高望重髻髮斑白還是年輕嘻哈紅顏綠人，完全沒有直接關係。 我為什麼要自掏腰包去的原因很簡單： 一來，類似的非技術型社群聚會，鮮有台灣賢達志士參加。 二是，較為正式和知名度高的會議或聯盟聚會等，資策會等單位雖然早用國家資源長期豢養自家或產官學人士出席，但風潮初起時的社群聚會，台灣官方或商業界多半萬斤身軀且嗅覺遲鈍，無視願等西風東漸之潮，待大腕發給門票入場時，局早已成，僅能啃食秣肉或淚泣為他人做嫁還要掛個「台灣之光」的狗牌。我等雖非有力人士，但鼻子還靈，行動體質良且好。去一趟演個小戲碼，花不了多少錢的。 三再，就是台灣在開放政府資料 (open government data) 也有薄弱和強大詭異的進展願景，在華沙現場若有機會報告，不失民際力量發揮。 四則，近來每年要到歐洲騎摩托車一次，波蘭曠野平千里，此季雖小寒陰霾交迫，但機不可失，仍執意 Honda CB 500 老車租賃前行。 歐盟副總理 Neelie Kroes 為此營隊背後歐盟勢力的領頭羊之一，至少 camp 開始的一段錄音致詞算是相當的有誠意。雖然後來被如 openlylocal.com 等實業家的 keynote speakers 三不五時消遣，但歐盟的六位輪值副總理當中至少有一位在 twitter 上活躍，且願意說出 open data 一詞，這就是開放資料正式進入歐盟政治的敲門磚了。當然有人提醒現在是關鍵，本次 camp 的社群氛圍和決議（如果有的話）將隱約昭示未來開放資料在歐盟各國的呈祥態勢，或是落入卷宗三十五年再起不能。 開場為 Rufus Pollock (Open Knowledge Foundation) 創辦人、在歐盟協助歐盟副總理 Neelie 處理 Digital Agenda 事務的 Carl-Christian Buhr、Sunlight Foundation 共同創辦人兼執行總監 Ellen Miller、實業級的運動者 David Eaves，以及波蘭 Creative Commons 計畫之負責人 Alek Tarkowski。 事實這樣型態的營隊頗有趣。以參與者來說，你可以說它是一個嚴酷的試煉場。因為若參與者不善溝通且所代表的利益組織和團體無法引起他人興趣，那麼結果可能就落得僅能在旁邊喝茶裝忙，永遠是角落的那一個。飛過去參與營隊是否值回票價，就端看參與者的本事了，例如社交推薦度、代表組織名號是否響亮等。但營隊畢竟是營隊，不是正式場合，也不是在比誰的拳頭有多大。例如享譽開放資料運動的 data.gov.uk 前總監也在場，但他並不會比來自摩爾多瓦的記者更令人歡迎。微軟 Azure 平台負責 OGDI 的傢伙也要對聽眾負責，若是太弱會被台下聽眾轟的。 因此若有辦法，一定可以拿到相當有價的情報以及對於未來發展有益的社交關係。在場者多半代表者一方勢力，北從挪威協助當地政府處理開放資料的民間機構、或是德國慕尼黑市的政府開放資訊計畫評鑑顧問，還是到肯亞的資訊官員等，關係情報唾手可得，就看你準備好接取這些話題了沒。 所以我才會自掏腰包、投書議題，然後也拿到一點 Wikimedia Foundation 的補助前往。這些都是遊戲規則和形式，在營隊確認的時程較為緊迫之下，免不了自己跳下來處理還是比較快。若是再尋國內管道找補助，到來時可能已是 2014 年，此波風潮早過，對學研單位來說，進場剛好，但對靠著判斷浪進而潮倡議行動者而言，這種時序的落差是完全是阻力。 當然，遊戲規則、利益團體以及參與的形式是否有利於我們想進一步了解 open data 在歐盟諸國和城市的推展狀況，這是事前要好好調查。去這一趟要拿到什麼，雖然看起來跟商業毫無瓜葛，但心理會有想拿到的東西。這是每次去參加會議或是營隊前的基本要求，簡而言之就是效益的評估和利益取得的來回驗證。這套手法在資源相對缺少，或是所代表的團體相對弱勢的狀況下，需要更精細的盤算。 首場一個半小時的揭幕式，由五位主持人輪番上陣演講。每位不超過十五分鐘，這也是多場社群活動在實證後所得之最佳簡報時間。事實上五位講者講什麼我全忘了，但每位所代表的角色以及會場的氣氛，卻是可以嗅出不少氣息。隱約只記得好幾個歐盟國家、城市，或是基金會在當日和十月底之前將陸續發表與開放資料有關的「作為」。Open Data (Government) 的倡議不過幾年，但卻能有一股隱藏的力量在推動著。這些作為可能是 open data portal（資料入口網）上線、open data license（開放資料授權）草案出爐、政治獻金資訊透明化草案列入歐盟大會討論議程（10月25日？）、哪個建基於開放政府資料的服務要測試……等。或是如西班牙政府本月才釋出的公共資訊再利用草案，還是各國權責單位紛紛在美國國務院的號召下，表白謹尊開放政府的立場 (Open Government Partnership)。有一個熱烈的氣氛在環繞著，至少相較於去年的第一屆營隊，這股風潮在檯面上已經是相當活躍。 檯面上的活躍是一種可以善用的情勢，至少我們可以看到台北市政府也在毫無預算的情況下，接受微軟 OGDI 和 Azure 的方案，推出 data.taipei.gov.tw。先不論背後狀況為何，我們在 opendata.tw 也談到了一些看法，但諸君或許不知，新加坡的 data.gov.sg 也是用同樣的解決方案。 以上訊息都是在會議第一天第一個半小時的部分觀察。但這些訊息要成為系統性的資訊，然後落實到本地的作為，前者其實也不是很難，但需要有智庫型的團隊來承接，也可以運用網路協作體系來進展。後者顯然需要投注更多，這包含開發社群關係的營造、基金會運作資金的準備、團隊的招募、志願體系的籌備、媒體關係的搭理、以及不少事務要拉進來考量。 [源碼新聞] 歲末年終大掃除，維基冬聚談除錯2012-01-16 14:19 作者是 Reke 2012 年 1 月 7 日，再過半個月左右就是農曆新年的到來，也是維基百科台灣社群 2011 年冬聚的日子。在歲末年終的時候，來個除舊佈新是華人的習俗，中文維基百科將近 40 萬的條目，也需要好好的清理一番了。比起英文維基百科來說，中文維基百科的條目素質往往不是那麼令人滿意。因此許多維基百科的編者、讀者，就在這場盛會中，一起來探討如何能夠為維基百科除錯，讓內容更完善。 維基編輯經驗談，收穫滿滿 上午時段率先開場，是由 2006 年起就投入編輯的 Supaplex 進行為時半小時的專題演講，題目是「為何犯錯？怎樣除錯？」。Supaplex 先從各方對維基百科的想像切入，勾勒出維基百科「協作」觀念的實際運作方式，再從寫作者的專業性、視角的侷限等等方向，分析出錯的種種原因。最後再提出多項建議，從個人對資料的收集到尋求其他維基人的協力，給予在場參與者許多實用的參考。 ▲ 圖1 Supaplex 的專題演講。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 緊接著登場的是「條目維護面面觀」座談會，由三位活躍的維基編輯者擔任來賓，從條目維護實際經驗的分享，讓所有在場的參與者能了解維基社群在條目維護上嘗試過的多種方式，以及面臨到的難題。 「魔法設計師」是台灣最早參與百科編寫的資深維基人之一，分享了早期「台灣主題」頁面，由幾個朋友聯合，共同更新特定條目的經驗。他認為現在網路溝通的平台更多更便利，要發起這樣的合作更方便；然而也因為方便的工具太多，反而造成力量的分散。如何克服缺點保留優點，給有心協作的維基人提出一個值得思考的方向。「TX55」則是主要以單打獨鬥為主，但是喜歡寫 ACG 主題條目的他，在創作過程中也有碰到 ACG 專題成員主動參與協助。他從個人條目創作者的角度，也提出了對群體協作機制的見解。「安可」則是目前「條目質量提升計畫」的總主持人，不但分享了多種形式的合作經驗，同時也注意到討論氣氛對於協作平台是否活躍有一定的影響力。 ▲ 圖2 座談會講師，由左至右分別為魔法設計師、TX55、安可以及主持人 Reke。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 ▲ 圖3 座談會實況，TX55 的分享。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 創意討論火花多，跨國研究眼界開 經過一個上午的分享，不管是已經參與過編輯的老手，或是從未有編寫經驗的讀者，都對維基百科的除錯機制有了認識以及新的思考。因此下午的時間，就以類似 Unconference 的型式進行了一個小時的創意討論會。會中主要觀注三個焦點，第一是如何讓更多的專家願意參與維基百科的編輯，第二是如何建立更容易協作的平台，第三則是如何協助編者解決資料搜集的困難。與會者無論參與維基編輯資歷的深淺，都在主持人的引導之下，由自身經驗出發找出問題，並在集思廣義的情況下提出可能的創意。 雖然短暫的討論時間並沒有辦法提出完美的計劃，然而在熱烈的氣氛之中仍然併發出許多創意的火花。例如在促進專家投入維基的方法上，與會者認為要讓忙碌的教授投入維基寫作有一定的難度，但是可以從吸引研究生的編輯興趣為主，藉由師生的關係引入專家級的識見；至於吸引學生族群投入編輯的方法，則可以考慮透過網路媒體的宣傳塑造出明星化的維基人，激發參與者的榮譽感。又例如在討論如何建立協作平臺的小組，試著在列舉出理想平臺的條件之後，把網路上常見的服舉務拿來「超級比一比」，為它們各項條件打出分數；經過數據化的衡量，精挑細選出郵件群組服務做為目前最理想的協作小組溝通平臺，為社群未來建立合作機制，提供了相當具有參考價值的建議。 ▲ 圖4 分組討論實況－那些年，一起寫的維基。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 有了台灣維基社群的創意激盪，本次活動更進一步擁有了國際級的視野。出生德國、目前在維基媒體基金會 (WMF) 服務的 Tilman Bayer，透過中文現場口譯，提供了「關於維基百科可信度的學術性研究」簡報。簡報中指出英文維基百科的條目雖然可能有一些深度不足的問題，但是在資料正確性上，許多領域都有極佳的表現，堪與專家編纂的工具書匹敵。雖然報告中指出，針對其他語言版本的研究資料目前仍不足，但是英文維基的輝煌成果仍可做為中文維基百科的編輯者追求的目標。 ▲ 圖5 Wikimedia Foundation 負責 movement communications activities 的 Tilman Bayer 來到活動現場演講，題目是「關於維基百科可信度的學術性研究」。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 大小維基聚會，邀您一起參與 雖然精彩的冬聚活動已經結束，但是對於維基百科除錯、提升品質的工作，這只是一次開端而已。擁有近 40 萬條目的中文維基百科，內容的生產、編輯、排版、修正、維護、更新等工作，都是由志願者無償投入時間心力來完成。因此需要更廣大的編輯隊伍，才能夠更全面地改善所有條目的品質。目前台灣已有台北、台中兩地社群有固定的聚會，南部的台南社群也力圖重啟聚會。這些小型但頻率較高的地方聚會，除了維繫維基人的感情之外，也肩負著編輯技巧分享的任務。錯過了這次的聚會沒有關係，記得到維基百科上注意台灣各地社群聚會的消息，只有透過您的熱情參與，才能讓中文維基百科成為最可靠的網路工具書。 ▲ 圖6 活動大合照。出處：Wikimedia Commons，Harenwang 拍攝，採用 CC-BY-SA 3.0 Unported 授權。 相關連結 中文維基百科2011年台灣冬聚活動頁面 作者簡介 Reke，台灣維基社群成員，PTT 電影板板主，主業為文字工作者。著迷於電影，耽溺於文字；在現實裡怯弱地柔從，在評論裡驕傲地反抗。電影部落格：http://rekegiga.blogspot.com/ [自由文化] 維基化．話維基(5)－「官方」的迷思2012-01-16 14:38 作者是 Reke 「官方」一詞，原本指的只是與政府相關的事物，但近年來已經成為對應英文 official 一詞的標準翻譯，指的是能夠代表一個機構或公眾的事物，不見得要與政府單位相關。所以雖然藝人大多不當官，NGO 團體標榜就是無官做，但是它們都可以擁有「官方網站」來表達「官方看法」。 不管是真官、假官，「官方」資訊的真與假在平日就已經是可能發生爭議的問題，而維基百科條目寫作時，官方資料的應用，更容易引起許多的爭議。尤其是有些維基人一下子說「以官方資料為準」，一下子又說「官方資料不可靠」，總讓人有些負面的聯想。事實上，這是出於一個迷思，若能拋開官方、非官方的名義，以維基化的眼光來看，則這樣的迷思自然會減少許多。 官字兩張口，真的可靠嗎？ 從中文原始的「官方」定義出發，就從政府單位的資料是否可信開始討論。在一般的情況下，政府單位發佈的統計數字，在準確度上擁有無可匹敵的優勢。因為非政府機構的統計值，多半受限於經費、人力等資源，只能採用抽樣、推估的方式取得；而政府透過行政官僚體系的資源，加上握有法令的強制力量，許多數據可以進行最完整的「普查」。另外，官方的研究往往表現較為保守，怪力亂神的傳說或是誇大的敘述，較不易出現在這樣的材料中。 然而，若要說政府部分的資料絕對可信，肯定會引起抗議。稍微具有獨立思考意識者的人都可以舉出世界各國政府隱瞞真實數據的案例，在中文維基百科主要使用的區域，像台灣政府在 228 事件的調查、中國政府在幾項災難死亡人數的統計上，都可以讓人揶揄「至於你信不信？我反正是信了。」的確，在面臨可能使政府顏面無光的議題時，「官方」數字極有可能受到一定程度的扭曲，這時候完全將其視為絕對可靠的權威，就昧於事實了。 ▲ 圖1：在台灣，主計處經常發佈各種政府官方統計資料。 維基百科重視可供查證的資料，同時也強調這些資料的可靠度，避免虛假、杜撰的知識能藉由粗糙的出版品進入維基百科。面對可信卻又可疑的政府資料，並不能夠單單憑著來源就烙上「可靠／不可靠」的烙印，也因此造成一些紛擾。尤其在政治敏感的議題上，往往會有陰謀論者認定政府全然造假，對認為政府資料可靠的維基人視為狼狽為奸的份子；同時，也會有保守份子對政府灌輸的概念全盤接受，將民間的資料都貼上不可靠的標籤試圖消音。兩種人一旦盯上同一個條目，編輯大戰難以倖免，甚至介入調停的中立者也「公親變事主」，被貼上標籤後成為遭到怪罪的對象。 事實上，對於政府單位的資料，我們並不需要站在非黑即白的二分法上，直接斷定絕對的可靠或不可靠；比較恰當地做法是，檢視條目內容與政權之間的利害關係，個別地評估。與政權利害關係越緊密著，越應該參考多方的觀點，綜合地引述；而較無利害關係的資料，調查樣本數較大的官方數據，自然可靠度就要比其他的數據高多了。 官方不可信，難道要信小道消息 政府單位的「官方」讓人煩惱，民間的「官方」則面臨了另外一項問題。在〈維基化‧話維基〉的第四話中，我曾經提到了「觀注度」方針產生的爭議。許多藝人的粉絲會在編寫條目時，面臨引用官方網站的資料卻被維基人提刪。而過程中無論是未得到解釋、或是解釋的人引用的方針指引出現錯誤，經常讓粉絲們誤以為這個資料來源不被承認，是因為被維基人定義為「不可靠」來源。這樣的解釋會造成誤會是理所當然的，在追星族所接觸的資訊中，後援會、少數「有內線」的歌迷經常小道消息滿天飛；而雜誌、報紙影劇版又充斥著八卦。這些消息才是不可靠的來源，而官方發布的澄清或是證實，才是最可靠的資料。維基人卻寧可相信第三方的報章、而不願承認官方網站資料，實在是太不可理諭了。 這實實在在地混淆了兩個範疇：正確性、重要性。來源的可靠性只保證了條目內容的正確，卻無法為條目的重要性背書。舉個例子來說，有一個從不說謊的人，告訴我們「小明的爸其實是隔壁的老王」，這件事情正確性沒有什麼問題，但這個「小明身世」的重要性實在不足以錄入維基百科當中。 ▲ 圖2：維基百科上香港電視節目「頭條娛樂」曾因為只有官網來源，被依關注度不足提刪，引發長篇爭論。 官方網站之所以不能夠當作觀注度的依據，主要是因為在網路時代，設立官方網站、自己發佈訊息的成本極為低廉，幾乎任何人都可以擁有自我宣傳的空間，這些空間的存在當然難以證明條目的主體受到足夠的觀注。不過，在來自第三方的資料來源能夠足以證明條目本身的觀注度之後，官方網站上的訊息，只要不涉及利害關係的部分，大致上都是比其他來源更加可靠的。換言之，這些「官方」出版品並不是維基百科上絕對不能接受的禁區，對於維基人不接受官方訊息的誤解，可真是不白之冤了。 甩開官不官的迷思 官方也好、非官方也罷，在維基化的思考裡，這並不是評估資料的絕對準繩。前文說了這麼多，說穿了，一份資料可靠度，還是回歸到兩個層面來考察。 第一個層面是這份資料是如何生產的，是屬於內在的因素。以統計數據來說，就是指普查或抽樣、樣本數的多寡、問卷的設計嚴謹與否等等的變數。而第二個層面則是這份資料在什麼情況下生產，是屬於外部的因素。例如發表資料的單位或其資助單位有無利害關係、主筆者是否有特定動機、發表資料的地區是否有學術與言論的自由等。 除了了解以上的考察準則之外，對於越是專業的、重大的題目，越應該明白可靠度不會是一個 1 或 0 的二元值，而是一個 0%～100% 之間可能游移的值。最好能比較多份資料，才引用最可靠度較高的一份；甚至，可以引用維基百科另一個重要的方針：「中立的觀點」，將有一定可靠度的各方不同資料皆加以並列。如此，則可以跳脫「官方」的迷思，不再為了這份烙印與維基的伙伴起爭執。 作者簡介 Reke，台灣維基社群成員，PTT 電影板板主，主業為文字工作者。著迷於電影，耽溺於文字；在現實裡怯弱地柔從，在評論裡驕傲地反抗。電影部落格：http://rekegiga.blogspot.com/ [接案 / 工作] PHP Senior Developer – Zalando Taiwan2012-01-13 13:54 作者是 Zalando Taiwan Rocket Internet, based in Berlin, is the largest European incubator for the establishment of successful internet e-commerce models. In the past few years, we have become a strong partner for numerous successful companies in supporting them with our unparalleled online expertise, network of contacts and equity. Some of best-known projects include Groupon, Zalando, Wimdu and eDarling. We are looking for junior and senior PHP developers to join our Taiwan team of developers building several online businesses starting with Rocket Internets venture Zalando - one of the top fashion e-commerce websites in Europe. Criteria for senior developers Excellent XHTML and CSS knowledge Advanced understanding of Object Oriented Programming Advanced knowledge in PHP and Javascript Advanced exposure to PHP MVC frameworks (Zend, CakePHP, Yii) and jQuery Ability to communicate across business and technical audiences 3-4 years web development experience Excellent problem solving abilities Must be a self-starter with highest of professional standards We offer Ongoing training and exposure to latest technologies Mentoring from above and client exposure Ownership of projects Great work environment Flat structure and organic roles How to Apply Please apply today by sending your application to zalando.php.taiwan AT gmail.com Subject: Junior Web Development [接案 / 工作] PHP Junior Developer – Zalando Taiwan2012-01-13 13:57 作者是 Zalando Taiwan Rocket Internet, based in Berlin, is the largest European incubator for the establishment of successful internet e-commerce models. In the past few years, we have become a strong partner for numerous successful companies in supporting them with our unparalleled online expertise, network of contacts and equity. Some of best-known projects include Groupon, Zalando, Wimdu and eDarling. We are looking for junior and senior PHP developers to join our Taiwan team of developers building several online businesses starting with Rocket Internets venture Zalando - one of the top fashion e-commerce websites in Europe. Criteria for junior developers Excellent XHTML and CSS knowledge Solid understanding of Object Oriented Programming Experience with PHP and Javascript essential Exposure to PHP MVC frameworks (Zend, CakePHP, Yii) and jQuery highly desirable Ability to communicate across business and technical audiences 6 to 12 months web development experience Excellent problem solving abilities Must be a self-starter with highest of professional standards We offer Ongoing training and exposure to latest technologies Mentoring from above and client exposure Ownership of projects Great work environment Flat structure and organic roles How to Apply Please apply today by sending your application to zalando.php.taiwan AT gmail.com Subject: Junior Web Development