[心得] 從「台北公車」 app 的下架看資訊引用這回事

Lion

前幾日，台北市政府將 Android 上頭擁有多項作品的 mywoo 其中一項作品：「台北公車」給斷了資訊來源。「台北公車」是一個可以觀看台北市公車到各個站點抵達時間的 Android APP，同時能夠將常用的點存成我的最愛。而無法更新資訊的「台北公車」就等於被否定了他作為一個 APP 的存在意義（想想看一個不能上網的網路瀏覽器？），這件事情引起了大量的迴響，有人認為台北市政府鴨霸，有人認為作者 mywoo 利用的方式有問題，也有人認為該程式是免費的，作者並沒有從中獲利，甚至台北市政府自己也有出公車 APP 要排除競爭才故意斷第三方的路。

▼ 目前下架的「台北公車」。目前的協調方案是 APP 從 MARKET 下架，但其程式能夠繼續運用。

台北市政府的考量

首先我先引原作者 mywoo 所發表的全文

「大家好!我是 台北公車 作者 mywoo,謝謝大家的支持! 感謝台北市政府,重新開放部分網站連線. 感謝新北市政府,維持正常連線. 台北公車 至今 2年了 智慧手機環境變化太快,開發者應體認現實, 2年前寫 台北公車 時空背景,跟現在天南地北, 當時數千人使用,政府機關歡迎您來,推廣他的網站 現在一個App,動輒10萬人下載 市政府主機受不了,而且他也有自己程式 所以會要求您申請資料介接,自行負擔主機與頻寬費 我把 台北公車 下架了,不要讓事情惡化. 現有程式仍可使用,讓事件隨時間慢慢淡化吧 我沒錯,台北市政府也沒錯,只是環境變了 依賴的人,必須離開 開發者也必須調整方向,App不要再走政府網站方向,情勢已變, 政府鼓勵開發App,各機關都會推出自有App 熱門的交通,氣象,新聞未來可能都會面臨這些問題」

▼ 原作者於 Mobile01 論壇發表的文章。（來源：Mobile01）

從文中可以知道，其主要的原因是在於台北市政府的主機無法承受成長過快的壓力。這其中所牽涉到的問題以台北市政府的角度來說，一個第三方所開發的 APP 在一開始，台北市政府是很歡迎這樣的應用的，而流量逐漸增加，慢慢的主機受到壓力，如果是網管，第一個開刀的自然就是第三方----不是我們自家所產的----或是去檢討流量使用最大的管道。而「台北公車」看起來似乎就佔了其中兩個條件。

以市政府的考量，每期所編的預算都是有限的，用完了就要等下次編列預算。而流量、主機在在都是要錢的，在無法即時開源的情況之下，節流就是必要的措施。而「台北公車」的寫法也犯了大忌，其 APP 直接開了一個 WebView 來呈現整個程式畫面。也就是說他不是撈資料後自己去渲染出畫面，而是使用了市政府的主機資源來作。

爭議點在於資源的運用方式

以這起事件來說，台北市政府在第一時間成為了眾矢之的，原因不僅是擋掉了「台北公車」的資源或是要扶植自家的 APP（台北好行），而是「公資源」是不是能完全為國人所運用的問題上。這邊我再引 APP 作者的回文：

「我提出 一個方向 大家討論看看 公車動態資訊,台北市政府要求開發者申請免費資訊介接 開發者 須自備主機,傳輸給 使用者,因此須負擔伺服器,頻寬等費用,必須向使用者收錢 結論是:使用手機程式,查詢公車資訊要付費,用瀏覽器上網查詢,免費 我不認同 會產生 要收費 的資訊介接政策 台北公車 2年前 從0到18萬,是台北市政府 默許 養大的 年初 12萬人時,還擴充伺服器,到18萬時,拒絕繼續服務 經反應,開放部分使用 我猜測原因是,下載每個月 以 2萬人 速度成長,太快了 衝擊 預算分配,政策方向等,不停不行 公車即時資訊,值不值得,政府擴大預算,雲端伺服器,火速加開? 把即時資訊給開發者,讓開發者向使用者收錢,合理嗎?可行嗎? 螞蟻雄兵,行動通訊時代 已來臨,這只是問題的開始」

▼ 原作者於 Mobile01 論壇發表的文章。（來源：Mobile01）

從這篇回文可以看出，其實問題非常單純，就僅僅是台北市政府的主機被炸得受不了只好砍流量而已。但延伸出來的問題就很值得思考----如果說一個第三方程式做得比原生的還好，那原生的資訊提供者把第三方程式給斷掉是否會落人口實？以這個 case 來說，台北市政府有提供 api 來申請的，但只能把資料撈出來，要把畫面送出來還是需要一個主機來中介運算。這也是台北市政府的用意，將流量與主機的壓力分擔給第三方開發者，簡言之就是要用可以，自己架一個主機自己維護，資訊給你沒問題。如果將問題導到這邊，那就跟 app 本身是否好壞沒有關係了，僅僅是一種商業道德的問題，畢竟流量是有價且還真的不便宜的。

以之前的例子來說，像無名所發生的幫學弟 測流量事件，與朱學恆的一個噗浪不小心就把別人的主機給炸了，這兩個事件都可以代表引用與攻擊其實只是量的差別。當然無名的事件看來跟傾向於比較負面意含，但朱學恆的事件就比較是無心之過。在上一代網路革命時，各種網路服務的，嗯…比較潮一點的說法叫做「翻玩」，各種服務的 Mash-up 各種服務的混搭是非常受歡迎的應用方式。舉個例子，就好像我們現在在 BLOG （一種網路服務）裡頭嵌入了一個 Youtube 影片（另一個網路服務），而 BLOG 的側欄可能還嵌著一個 PLURK 的訊息欄（也是另一種網路服務），如此的交互搭配使用不但非常流行，且也真正的讓整個網路瀏覽體驗大大地增強，但這些都是有價的，也就是說這種服務都是要錢來支撐的（或是從讀者身上賺到錢）。以朱學恆噗浪事件為例，將圖片直連的行為善意點稱為「引用」，難聽點稱為「盜連」。而被「引用」的主機主人希望朱能夠將圖片傳到 PLURK 的主機上頭，而不要直接連到他家的主機（以免被打掛。）

這個例子就跟此次 mywoo 的「台北公車」事件如出一轍，在使用人數很少時可能主機主人還不會在意，但等到主機快被炸掉時主機主人就會希望使用的人能夠分流到自己的硬體上去（如北市府要求說要用資料可以，但先抓到自己的主機再分出去。），單純的來說，這就只是「錢」的問題（要增加流量或主機都必須要編列預算），與其他是否公資源必須給大家所用，或是說北市府在庇護自家的 APP 都有一段距離，而作者如果真的自己去購買主機，並且使用北市府的資源後，為了回收投資而向使用者收費，這問題又會變得更為複雜（引作者 mywoo 前頭所述說的。）

數位時代的道德與禮節

在我自己寫 BLOG 時，通常附上來源的連結是必須要的，而我也會重新上傳到自己的主機（縱使我的 BLOG 流量應該不會對任何人造成影響），這不單是以防連結失效，也是一種對對方的禮貌。而相關的版權問題會扯到更大的議題，在此暫且按下不表，我自己的文章是使用了創用CC的版權保護，不過定得很寬鬆。正如 mywoo 在回文中所說的，「行動通訊時代 已來臨，這只是問題的開始。」應該怎麼作，我們都還在摸索，但不造成他人困擾是最好的準則。

▼ 我所採用的創用cc方案。（來源：創用cc）