Monthly Archives: February 2014

關於 “Open” 這件事

昨天在 MozTW Lab 臺北場採訪 MozTW 社群聯繫人 Irvin,席間可能是因為我們談到 Mozilla FoundationMozilla Corporation (MoCo) 的差異,以及我名片上印著「開放標準推動者」,引來了另一位 MoCo Taiwan 朋友以及 littlebtc 加入討論「關於大家各自認知的『開放』是怎麼一回事」。

因為我當場忘了基本禮數,請教這位長輩尊姓大名,所以在此容我以「MoCoTW 君」稱之,並請注意在此這只是代稱該位長輩,請不要誤會我上綱到 MoCo Taiwan。

我的立場是,基於我的 Library & Information Studies/Science 的專業,其實我近年來漸漸由高中開始信仰的 Free Software(自由軟體)往 Document Freedom(自由文件)「雙修」。我意識到如果光打著 Open Source 名號、沾 Open 的名聲,卻做一些封閉介面的產品,把使用者生產的各種數位資訊鎖著,表面上你用得開開心心,實際上你卻是個奴隸,且是個自我感覺良好的奴隸,那並不符合我對資訊自由、平權的正義觀。

MoCoTW 君在最後問我說:「假設某廠商做一套不管是開源還是私有軟體,但是他們皆有公開這軟體產出的檔案格式,不過卻經常、頻繁地改動,這樣的『開放』是我可以接受的嗎?」我基於一個 Librarian(再重申一次,我不喜歡「圖書館員」這個因襲下來的譯詞,而比較愛用符合其本質定義的「資訊看守」之類稱呼)的專業,表示當然可以接受,因為如果該廠商確實以明文且有效的授權條款,開放這個檔案格式,那麼我在任一處資訊機構(包括狹義的「圖書館」)只要用到這個檔案格式,我都可以安心使用。我不用擔心這個廠商哪天倒了,或是後續服務愛理不理,影響我機構內使用這個檔案格式儲存的資訊的存取,我可以保證只要我遵循這個檔案格式定義去寫「解碼程式」,我都可以完完整整、毫無漏失地把檔案讀出來,再做後續處理、利用,且這樣的解碼行為,不會無端惹訟。

這樣的數位典藏,我以為才算是真數位典藏。

而 MoCoTW 君會這樣問我,可能是因為我與 Irvin 在談論 Mozilla Foundation 與 MoCo 的差異時,言談之間讓他認為我們帶著反商情結去看 MoCo 在做的事情,接著帶到 Linus 對 Linux 的 GPL 版本選用、Google 對 AOSP 的「開放」方式等例子,想要表達「現實是這些在授權方式上、手腕上、作法上的妥協,才使 Open Source 的商業化有活力,極端如 FSF 者光靠推『理念』並不能當飯吃」 。廠商如果遵循遊戲規則(授權條款)做事,可能依授權條款沒有義務一定要 Open Source,而就算照規則得 Open Source,也沒有義務要維護「Open Source 出來的那(個、些)版本」,在商言商,如果廠商確實照規則來做事,就不應該再受到道德上的批判。

關於這點,從近期 Mozilla Firefox 在討論 new tab directory tiles 要放網站廣告的爭議例子,可以看到說,如果「投放網站廣告」要追蹤績效,就可能勢必要「追蹤使用者行為」,站在 MoCo 必須營利來經營下去的立場,以及 Mozilla Foundation 堅持捍衛隱私權理念的立場,就會有所衝突。同樣的,MoCo Taiwan 推出的 Firefox 臺灣版事件也有類似的爭議。

那麼,Mozilla Foundation 這邊的 Mozillians 所批判的,是 MoCo 這邊對理念的妥協、棄守,而不是針對追求營利這件事。如果 Mozilla Foundation 必須藉著 MoCo 把理念打折來維持,那麼 Mozilla Foundation 就只是為了存在而存在,而不是為了其堅守的理念而存在。其他公司可以把 Do No Evil 之類的口號可能只用來妝點形象,而 Mozilla Corporation 的成立初衷讓它沒有任何餘地可以賴皮,至少必須面對 Mozilla Foundation 的檢視。

進一步推回前幾段的「照規則來 Open Source,就不該再受到道德上的批判」這點,如果今天 Firefox 有個功能是會侵害隱私權的,那麼就算開發者將該功能的 source code 完完整整、毫無保留地照授權條款 open 出來,這只能滿足「你確實照規則來做事」這點,但是並不表示「你這個功能是符合 Mozilla 信念的」。

(以上是我個人的想法記錄整理,不代表 MozTW)

買了 Apple Wireless Keyboard 2011 日本 JIS 版暨第一次送 Linux kernel patch 就失手

DSC_1155

因為在辦公室使用的 Ducky 1087 機械式鍵盤,聲響屢屢受到同事側目(特別在我碼得特別來勁、或遇到解不掉的 bug 時),所以決定忍痛賣掉,這裡說的忍痛不只是心痛,還有左臂長期以來的疼痛。無論如何,我還是需要一個方便工作、好打(或至少不難打)的新鍵盤。

然後我調查了一下,扣掉會吵到、嚇到人的機械式鍵盤,符合「方便工作」、「好打」條件,再加上「不要 100% 大小」、「我負擔得起」的款式,其實沒多少可選,於是我就買了 Apple Wireless Keyboard(2011年版)。

照片上有兩「片」鍵盤,沒錯。家裡的 Mac mini 搭配的 Apple Pro Keyboard 在經年累月的耗損之下,也愈來愈會卡鍵、愈來愈難打了,所以一不做、二不休,一次買兩片,宜蘭、臺北兩處用。因為網拍上有很便宜的日本 JIS 式排列版鍵盤,而我本身對日文打字還是有一定程度的需求,所以 JIS 式排列版鍵盤對我來說算是實用。

Mac mini 搭配 Mac OS X 用 Apple Wireless Keyboard 當然是沒有問題的;但是我平日使用的主力 ThinkPad X230i / Arch Linux / KDE 則不免需要折騰一下。

雖然它看似可以被 Linux 正常驅動,但是很奇怪的就是 ‘fn’ 鍵沒有作用,這代表我無法使用 fn 鍵搭配四方向鍵操作 Home, End, Page Up, Page Down。

我追蹤了一下問題成因,利用 bluetoothctl 掃描硬體資訊,發現 hid-apple 模組並未納入 Apple Wireless Keyboard 2011 的 JIS 版,也就是廠商代號 (vendor ID) 0x05ac (Apple)、產品代號 (product ID) 0x0257 不在其中,所以針對 fn 鍵的程式碼未能正確套用在這款鍵盤,這款鍵盤被 Linux 當成了一般的藍牙鍵盤來驅動。

於是我把缺少的幾行程式補上去、證實可以正常使用 fn 鍵之後,開始了我跌跌撞撞的送 patch 歷程。

一開始我跑到 Linux kernel 的 Bugzilla 系統去回報,卻沒有看清楚這是給 mainline 使用的,在上面回報 3.12.9 的問題,一開始就錯了,而我沒有確實讀過 Documentation/SubmittingPatches 文件,沒有照正確的格式、方法,只是憑著「我找到解法了」的小屁孩樣的熱血、如無頭蒼蠅般亂竄,還被 Alan Cox 大神回以簡短一行提示,實在是很慚愧。

接著我改往 linux-input mailing list 上面送 patch,無奈可能還是因為不得要領,過年這幾天還是見不到我的 patch 被維護者 review 的跡象。

於是我跌跌撞撞地反覆修正我的 patch,最後才發現使用 git format-patch 搭配 git send-email 是最簡單省事的。畢竟 Git 原本就是為了維護 Linux kernel 而生的。

用 Git 從 The Linux Kernel Archives 抓回 mainline (此時是 3.14-rc1)的 source code 後,先 git checkout -b apple-hid 用一個新的分支來修問題。

把問題修好後,commit 異動,此時編輯 commit message 請記得遵循規定格式。第一行會被當成 commit 的標題,請照類似這樣的格式寫:

HID: Add Apple wireless keyboard 2011 JIS model support.

開頭要標明這份 patch 是屬於哪個子系統 (subsystem),譬如我這次送的問題是屬於 HID (Human Interface Device) 子系統,就要確實標明。

跨一行後,敘述此 commit 的主要目的、功用等說明。這會被當成 commit 的內文

Commit 完成後,就可以使用 git format-patch –stdout –signoff master 先以螢幕輸出檢查這份 patch 信件(是的,git format-patch 此指令會輸出一份標準的 Unix mail 格式文件)是否確實遵循規範,如果有錯誤,則可使用 git commit –amend 回去修改 commit message。

確認無誤後,則使用 git format-patch –signoff master 正式輸出 patch 檔,檔案會以「流水號-標題.patch」的格式命名。

接著請先跑過 scripts/checkpatch.pl 檢查剛剛產生的 patch 檔還有沒有嚴重的格式問題,再跑 scripts/get_maintainer.pl 找出此次回報 patch 時,應該送給哪個 maintainer、送到哪個 mailing list。接著可以去 subscribe 該 mailing list 取得發文的權限。

然後就可以用 git send-email –to <mailing-list-email-address> –cc “maintainer-email-address” –smtp-server <smtp-server> –smtp-user <smtp-user> –smtp-pass <smtp-pass> –smtp-encryption <smtp-encryption> <patch-filename> 把 patch 送到 mailing list 並寄送副本給剛剛從 get_maintainer.pl 得知的 maintainer。

我今晚照這個流程跑,maintainer Jiri Kosina 在幾分鐘內就回覆我格式還有點小問題、需要再改,而我修正之後重發,接著剛剛就被接納了。往後,這款鍵盤在 Linux 上就可以爽爽用了,而我也因此機緣學會了送 Linux kernel patch 的方法,非常高興。