2014年5月20日 星期二

回應整理:「google為何輸給Oracle:判決書小整理」

這篇是有關上一篇Google vs Oracle的判決書的回應,因為有些朋友看完那篇後,覺得筆者寫得太爛不夠清楚,提了一些意見,我就把回應跟上一篇的回應一齊整理在這裡,大家可以…呃…參考參考:

首先先來回應強者我同學Bonoshi對中文整理意見:


>>>其實我不大能接受這個作者的論述但自己又還提不出有力的反駁,他很顯然是在為專利和法律這兩個既存的實體辯護,然後藉著說外國媒體全都錯了表現自己相當冷靜客觀,因為一切只不過都按照規則來……所以這個作者對法律本身沒有什麼反省,然後一會兒拿菜單一會兒又拿文學這些和程式設計不能相比的東西去比喻為自己的立場辯護,讓我覺得非常可疑

答案是:是的,因為這是判決書;事實上圖書館與文學的例子都是判決所提,圖書館的例子是地方法院所採用的比喻。
在新觀念出現的時候,法律可能會套用舊觀念來推衍新觀念適用的法條;著作權本來是要保護作者創作的事物而生的權利,無疑今天我拿筆寫下的文章無疑是有著作權的保護,那我用鍵盤打出來的文章是否類推?打出來的原始碼呢?
實務上被認定為有,軟體著作權是這樣一步一步推上來的,我相信這個問題在法學界跟過去的訴訟一定有被討論過:這部分可能要看早一點的案子Computer Assocs. Int'l v.s Altai,裡面可能有討論。
當然不無網路和軟體改變法學認定的例子:例如我買了軟體,但我沒有取得所有權而是軟體授權,所以我是不能讓賣書一樣轉賣軟體;blog放mp3我的確沒有營利,但仍可能侵犯著作權。
法律之解釋可能隨新事物的出現而有所變化,Michael Crichton所著的危基當前,就是對於基因被申請為專利現象的反思;但軟體的著作權,目前是個已定論的概念,本案更進一步確認即使是API,譔寫人仍擁有著作權。

>>>關於「但Oracle在創作Java 時,並非只有有限種譔寫API的方式:Math.max 可以寫為Math.maximum。」
這並不成立,max和maximum都是歷史悠久的單字,後者至少18世紀出現,前者19世紀。如果API必須以有意義的單詞(自然語言、高階語言)作為組合,那就是有限種,而且種類相當的少,不能和旋律、音符或文學作品相比。再加上程序編程又有所謂coding style和convention,max(x, y)顯然比bigger(x, y)還被廣為接受,而且我相信這也不是Java的發明。

這裡應該是我舉例不足,實際上不止是這樣。
因為命名的選擇性跟編排有極大的彈性,為何是Java.lang.Math.max,而不是Java.Math.max?
Oracle方的證詞顯示這些Java library在譔寫時,是經過數年的討論與測試,選擇出最佳的命名方式和class間的依序方式,而google直接複製了這個編排過的命名(包括函式、物件、套件),也是本次討論中的重點。

>>>關於「google在android中逐字的複製37個API, 7000行程式碼」37個API指的是API的命名(xxx.yyy.zzz),我查到的資料說Java API有168個package,不過我去算新版的又更多。以比例來說,這樣還不算太糟不是嗎?如果有人說抄了一個API的命名就算抄,那接下來變數和函式的名稱是不是都要像公司商標和行號一樣有版權來保護了XD

我覺得這邊只能透過個案討論認定,抄了一個max也許會被認定為合理使用,但google被認定為抄了'套件、物件、函式'整體架構的所有命名,如果我寫了一本書,有人抄了1/5的內容,這樣嚴不嚴重?抄了全本呢?只抄一行呢?抄了全本但把內容做random shuffle呢?
著作權的「合理」認定本身就是模糊的,所以才會說是「整部著作權法裡最大的麻煩」,但這類有點比例原則的問題,最簡單的判斷方式就是台語「謀郎安內」。
要把變數跟函式名稱要變做保護標的,被抄後要被認定是不合理,幾乎就跟我寫一篇小說設定女主角為「一個高中女生叫沈珈儀」然後要賠九把刀一樣困難。

>>>然後我很好奇7000行代碼到底是怎麼分佈的,是連續的7000行全抄,還是散落在各處?還有Java那方的實做總共有幾行?什麼樣就一致,是整行當中扣掉空白和tab之後的字串一模一樣嗎?(我假設是這樣)我沒有看過code我不知道,但是我覺得如果所有的程式碼當中,零零總總加起來不過只有7000行一致,要是我是Google我可以看過Java的實做然後把所有的變數名稱全部換掉、順序盡量改得不一樣(想一下資結如果A作不出來,拿B的來交,就會作相同的事),或是有些地方讀懂之後改成自己的方法,總之code改得很髒(也搞不好改得超乾淨,人家是Google耶……),最後比對之後沒有半行一致,可是這樣有意義嗎?

就我對Java的了解,應該是散落在各個java file裡面,google複製了前面的import, class name, class function declaration這些。
google在實作上是自行實作,所以應該可以預期google換掉大部分的變數名稱,判決書中有不少口語證詞跟文件證詞的部分,這裡我沒有細看。
而當然,爭議是在宣告的部分。

目前法院對軟體著作權並沒有任何界線,但有一套認定的程序在多次判決中被採用:(至少是non-literal code):abstraction – filtration – comparison。
Abstraction: break down the allegedly infringed program into its constituent structural parts.
Filtration: sift out all non-protectable material.
Comparison: compares the remaining creative expression with the allegedly infringing program.
詳細的內容我就不清楚了,但literal code中,法院會專注在filtration step (Mitel, Inc. v.s Iqtel, Inc.)

>>>要認真抓,應該要分析每一行的敘述結構(比如說int a = max(b, c)和int d = max(e, f)等價)和整個函式的結構分析,但如果用了敘述結構和結構分析,那問題就變成一個程式如果不是演算法,他的執行步驟到底能不能被保護。還有敘述結構這種可以和自然語言的句型相比的東西,根本不能被保護。所以我很堅持,智慧財產權法必須重新檢討過,法院拿圖書館和菜單來有點落伍又避重就輕。

這個問題有點複雜,我留到下面跟戰神Milk大大的問題一起回覆。

>>7000行程式碼一致很顯然Google是可以避開的。它沒有避開,那麼很可能代表它寧可不要創造出開發者完全不熟悉、但卻可以完全避開法律問題的東西(我們可以想想如果是微軟,它又會怎麼作XD)。在信仰上,Google可能自始自終就相信最後自己不會因為這件事件產生嚴重的法律問題。

我認為:是。因為重新訓練使用者比抄襲合解難上太多。
至於google信仰上是不是真的無惡意的這麼做?我這裡就不臆測了,但有評論認為,google遲早會以同樣的API抄襲理由來阻止三星發佈Tizen 平台。

--

接著是戰神Milk大大的質疑:


>>>是不是所有開發 C library 或實做部份 std function 的都應該要付授權金給標準制定協會?
不是,語言並不是著作權的部分

>>>那麼一個 function 的API制定出來之後,是不是就可以 prevent 別人使用一樣的API,除非你付錢?
以本案的判決來看,是的,除非你的API只有一種制定方式(就實務上來看幾不可能),或是使用某語言所必須,此時你的API可能會因此喪失著作權。的確不諱言,是否可能出現一些垃圾開發者先寫出一些程式碼,鼓勵所有人儘量使用;接著抽回授權開始一個一個控告?
因此我認為,所有的軟體授權都應開始正視這次訴訟的結果,修改軟體授權不溯及既往,發展不可否認的時間戳記。
事實上也有人認為這次判決能遏止大公司抄襲小公司發展的API,不過我個人對這樣成效是存疑,反而可能造成未來自由軟體授權更難推展,而是偏向保留著作權授權的後果。

>>>Java在部份 syntax 上等也借鏡了c++ 的 syntax,倘若concept可以受著作權保護,這樣Oracle公司是否應該付費給 C++ 標準委員會或取得授權?

不是,concept在美國著作權法102(b)內有明定:
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
概念是無法受著作權保護的,事實上這點Oracle也承認,任何人都可以使用Java的Package-Class-Method的架構,他們並不擁有架構的著作權,而是36個class,20 subclasses與362個methods的命名和編排著作權。

>>>追問:Java 對既有的 C/C++ syntax 做出 extend 是否會侵害到原本的 C/C++ 可能使用族群的數量?如果有就是侵權行為?

還是否,syntax不是著作權法的保障範圍,你拿另一個語言的syntax怎麼用都是你家的事。
以寫書的比喻來說:我看有人用英文這個syntax寫書大賣,所以我也用英文寫,那個人能告我嗎?

共同提問:

>>>軟體產業是否應該把 API 認定為著作,而法官的行為會對於軟體產業有什麼後果?

我認為這個問題相當複雜,我只好打混說一下。
此例中法官並沒有討論這個問題,他是基於現行著作權法對軟體程式碼(source code, object code)的保護下,對API作出類似的認定。
我認為這個問題軟體原始碼是否受著作權法時就會討論,相關判例見Johnson Controls, Inc. v. Phoenix Control Sys.
我必須說我認為著作權法這個概念本身沒什麼問題,今天我好不容易寫了一本書,別人真的可以全文複製,掛上它的名字然後再出版一次嗎?
但,軟體是一個如此詭異的東西,本質上是一個介在文學與數學的東西,一方面它透過數學的邏輯架構,用嚴謹的定義規範一系列的運算步驟;另一方面它又是人類和電腦溝通的簡化「語言」,能把人類思考的巧思融入其中。
http://zh.wikipedia.org/wiki/%E8%91%97%E4%BD%9C%E6%AC%8A
參考著作權的維基,因為思考本身是無法申請為著作權的,從而「演算法、數學方法、技術或機器的設計」無法申請為著作,對海龍公式申請著作權會是一件很奇怪的事情。
那表達這式數學公式的軟體原始碼呢?我們為何能對一個演算法的原始碼申請專利呢?如果有最佳的解題步驟,不是應該每個人都寫出同樣的演算程式碼?
但世界不是這麼簡單,程式又融入了每個人的思考、想法,所以寫程式還是被歸入著作權當中,因為除去基本的演算法,把程式一塊一塊堆砌起來,還是需要設計師的巧思與智慧。

「複雜不含糊,嚴謹不簡明」
軟體的專利和原始碼的著作權爭議,相信未來仍會繼續下去。

題外話:


相比這個案例,我會說禁止相容PRM的規定,跟著作權延長、工具生產者入罪的危害大得多。本案引用的相容性案例,甚至直接指認將自己的東西相容於先行者是可行的做法,我認為有這些判例在先,打造相容環境在判決中是被隱性保障的。
也因此我認為wine跟bumblebee這類利用反工程破解先行者的架構,再自行重權相容環境,法院基本上認為是合理,且無涉原著作權人的著作權行使。
註:google的確有試圖論述這點,但法院認定android是無法與java相容的。
但有了PRM跟工具生產者入罪的規定,現行的這個「判例見解」平衡會被打破,這部分我就不班門弄斧,相關資料請參考:
http://ckhung0.blogspot.tw/2012/02/sopa-acta-tpp.html

附記:

靠回應比判決書長是怎麼回事……拜託別逼我了T_T,我要寫論文惹,不過最後請大家跟我高呼一聲:「開源碼萬歲,甲骨文去死」(誤)

2014年5月16日 星期五

google為何輸給Oracle:判決書小整理

眾所矚目的Google vs Oracle在前幾日判決,Oracle逆轉勝了這一局,因為我覺得此案實在太過重要,所以筆者就下載了判決書全文讀了一遍:
http://cdn1.vox-cdn.com/assets/4431835/13-1021.Opinion.5-7-2014.1.pdf

以及早先一些整理:
http://yowureport.com/?p=11928
http://www.fosspatents.com/2014/01/api-copyrightability-to-be-confirmed.html

並整理重要的論點在此,雖然說有一堆專業用詞不知道怎麼翻,還請路過高手指教;本文歡迎任何人轉載,但請註明出處'http://yodalee.blogspot.tw/' 或 'yodalee生活筆記'
注意此文是判決書論點之整理,不代表yodalee之個人意見,yodalee的個人意見是'開源碼萬歲 甲骨文去死'(誤)。

--

判決書的開頭就先解釋了Java, android, 前次判決的相關狀況,這裡就不再次說明,相信會來到這個垃圾blog的人的科技背景應該都不錯其實是版主自己懶

我們就從法律上來看,首先要先確立幾個背景:
  • source code, object code 的確受copyright literal part 保護(不然你覺得copyleft是為何而起?)
  • Google 承認Java API 為original and creative,法院也接受這個論述,也就是Java API的確構成copyright存在的要件
  • google在android中逐字的複製37個API, 7000行程式碼
“google agrees that it uses the same names and declarations in Android”
google複製了例如java.lang.math.max(int x, int y)這類的宣告,但重新實作了底層的implementation code。
所以爭議點在於:Google所複製7000多行的API,究竟是否屬於著作權法保障的範疇?在此判決中認定API屬於保護範圍,並逐一駁回google的理由。

google用了幾個說法,試圖認定Oracle的著作權為無效或android為合理使用等。

1. API是否落入Merger doctrine?
Merger doctrine: idea, expression should be split
當某個概念(idea)只能用有限的表達方式表達,則概念與表達融合,該表達變為不保護。
例如:輪子是一個概念,你要做到'輪子'的東西必須是圓的(難道能做方的輪子嗎…),所以你不能將圓形的這個表達方式設為保護範圍,並限制其他人使用類似的表達。
此決定是決定於製造輪子的時候,而非有人被訴製造輪子的時候;假設今天方的輪子也是可以用的時候,製造輪子的那個人就擁有圓形表達的著作權。
類似的案例,Nitendo曾展示多種不同加密卡帶的方式,因而取得卡帶加密方式的著作權。

google主張java API的實作方式和Java的概念已結合,因此API無法計入著作權保護,而google自行譔寫真正受保護的implementation code,從而避開侵權問題。
但Oracle在創作Java 時(吃屎吧你,明明是Sun),並非只有有限種譔寫API的方式:Math.max 可以寫為Math.maximum,Android可以用不同method分類方式,不同的命名選擇、不同的譔寫方式而達到同樣的效果,無法證明表達和概念是合一,使merger doctrine無法成立。
唯一的例外是三個核心的java packages: java.lang, java.io, java.util,不過google對此沒有特別主張。

2. API為短句,無法保護:
這就如先前整理所說,短句之集合為保護之對象。

3. scene a faire doctrine: 原創中必要的要素或習慣之物品不可為copyright: 
If they re standard, stock, or common to a topic, or if they necessarily follow from a common theme or setting. Apple Compute, Inc. vs. Microsoft Corp.
比如要描述警察,你就描述警棍、配槍、制服、鎮暴水車,所以你不能對描述這些內容的文字主張copyright,要求別人描述警察時不能這樣描述。
Google主張:這37個API已經成為寫Java時不可拋棄的部分,因此37個API的copyright已消失。

法院說:scene a faire的概念並無法證明Oracle copyright消失,只能作為google侵權之防守;但google無法提出明確證據指出android使用這37個API是必要,這個論點在地方法院就被駁回。

4. interoperability:
google主張此舉是為了與Java相容。
但interoperability並不表示著作權之消失,這裡使用的判決是Sony Computer Entertainment, Inc. vs Connectix, Corp.跟一個類似的案例。
總之Connectix用反工程的方式,製作出能和Sony卡帶相容的遊戲機,被認定為合理使用,但不影響著作權的創造、原創本身;而Google也顯然不是使用反工程的方式,了解Java 如何運作,再自行譔寫相關的執行程式;更進一步說,android上的程式和Java也稱不上相容。

5. Fair Use:
這就是惡名昭彰的'合理使用',根據是107條:
for purposes such as criticism, comment, news reporting, teaching (including multiple copies for classroom use), scholarship, or research, is not an infringement of copyright.
例如我今天想要痛罵祭止兀是笨蛋,我用了他臉書上寫的文章,此時他不能主張著作權;這個部分需要個案討論,事實上fair use被稱為:
'The most troublesome in the whole law of copyright'

這裡法院駁回google的理由是:

android並非Java之'transformative',如上,我要用祭止兀的照片提出評論或新聞使用,就幾不能有任何更動,而必預全部引用,並用於其他用途;顯然android並不合這個標準;同時google並非non-commercial的使用引用來的Java API,在實務上只要有營利性的行為,幾乎都會使合理使用的論述效力大幅下降。

--

大概說到這裡,我知道這樣其實稱不上什麼整理,如果有人提出更多的問題,我會再整理判決書內的回應貼上來。
看完判決,我覺得Oracle是佔在上風處,不過很有趣的,近十年來科技業最重要的兩個案件:Apple vs Samsung,Google vs Oracle
贏家Apple 跟Oracle保護了他們最重要的產品,但是卻輸掉了市場
也許智財權與著作權在軟體的保護已經近乎無效,即使得到保護,卻不一定留得住顧客的心。

ps. 然後我剛剛看到TSMC 控告Samsung侵權案勝訴,嗯…………

2014年5月9日 星期五

以pull request參與github專案開發

本魯最近看到一個有趣的專案: qucs
http://qucs.sourceforge.net/
目的是要打造一個類似ADS, AWR一樣的開源電磁模擬軟體,基本上是個野心勃勃,不過實際上沒多少人參與的專案,老實說還真令人擔心,我覺得還沒到一般人可用的階段應該就會腰斬了吧lol
不過難得有個專案跟本科相關,就進去玩一下好了,看看bug report,爬爬程式碼還真的修掉幾個bugs

好啦都修掉了那就來送個Pull Request吧…這玩意要怎麼送來著?
這時就只好自力救濟,問問旁邊的AZ大神跟QCL大神,QCL大神還很給力的直接殺到我房間教我;另外自己查了一點資料:
http://stackoverflow.com/questions/14680711/how-to-do-a-github-pull-request

對github的pull request 整理如下。
註:我其實不是很確定這個步驟是不是完全正確,如果有錯請大神們不吝指正 m(_ _)m

Step 1: get project

首先先在github網頁上,喜歡的project上按fork,把它複製到你的github上。
接著用終端機clone你的github:
git clone git@github.com:username/project
這樣會生成一個本地的git repository,它的Origin remote 設在你的github上。
為了方便參與開發,建議連接上原project的github,才能隨時保持你跟project無時無刻處在同步狀態:
git remote add upstream git@github.com:mainuser/project
這樣你的本地git就會連上原始project的github

Step 2: Open branch

接著就來修改吧。

通常新手使用git都會在來個「master大蜈蚣法」,一個master一路往前衝;不過project一大的時候還是建議開branch,改用「master大開花法」,每個branch只做一點點feature,然後再merge/rebase回master裡,反正git 就是branch怎麼開都無所謂。
參與pull request的時候更是如此,通常這時候project已經相當大了;儘量讓project manager看到少量的檔案變化,而不是整個project的檔案都變過;每個branch取個簡單易懂的名字:bug編號,feature編號都是不錯的選擇。
git branch -b branchname
git checkout branchname
or
git checkout -b branchname

Step 3: Make modification

修修補補。

Step 4: Send pull request

pull request會比較原始的github(也就是upstream)的某個branch,跟你的github裡的某個branch,把相關的commit 列出來,讓管理人決定要不要把你的commit接到它的branch上。另外,如果你在master上面加點東西,然後原開發者接受pull request,也在他的master上面加一些東西,兩個master間就產生衝突,所以請務必確保你的master是乾淨的。
Git push -u origin branchname
在你的github上面產生一個遠端branch。
接著到對方的github,按pull request,比較對方的master branch跟自己剛產生的這個branch。
第一個pull request就送出啦。

同時,在對方表態之前,這個branch就不要再動了,如上所說,github會比較兩個branch的差異,所以如果送出pull request之後又有變化,這些內容只會算到一個pull request裡,而不是每個feature一個pull request出去。當然如果你被拒絕了,你也可以繼續在這個branch上做修改,改好了再pull request一次。

Step 5: Merge, clean up

等待對方merge你的branch,merge之後,github會自動問你這個feature的branch要不要刪掉。
或者也可以用
git push origin :branchname
來刪掉遠端的branch,另外要用
git fetch origin -p
讓本地端更新遠端刪除掉的branch 的資訊。

最後要保持你的project跟遠端是同步的:
git fetch upstream
git checkout master
git rebase upstream/master

完成的畫面大概會像這樣:

整體的流程就是:我在origin/master的地方fork對方的project,接著在本地產生branch bug147,修正bug,推到我的github(origin)上。
對方merge我的pull request,更新了他的github(upstream)的master,我再用rebase把我的master移到最新的狀態。
如果你是高手,一次修10個bugs之類的,這時可以用rebase把其他應該修改的branch rebase到現在的master上。

以上,祝大家pull request愉快,大家快點來開發各種open source project

致謝:

本文感謝AZ大神及QCL大神的指導。

2014年5月5日 星期一

我的核四見解

好啦我先說,我寫這篇文已經抱持著被戰爆的可能了,特別是我記得我FB一直都保持擁核的態度,然後有一次在一長串的討論之後,我朋友就發了個推文「擁戴科學的人,理應謙卑的面對質疑,不要把所有假設都以為是理所當然/我只是覺得擁核方的態度有點討厭」

嗯嗯啊啊O_O,我只能弱弱的OS「我尊重你,你尊重我」啦,畢竟對方是電力組博士,而且這個發文自己跳出來回好像有點自己跳出去被打臉怪怪的。

--

好的,那麼我們開始吧。
從科學面來看,我對核能是持樂觀態度的;對核四,我則認為需要評估。

首先是核能,一直被戰的高階核廢料問題,並不是沒有方法解決,做成MOX燃料或進發展中的反應爐反應到半衰期短的廢料即可;我說目前高階核廢最好的處理方式,就是目前溼式的處理方式,靜待更新的處理方式出現;或者等到阻礙處理的政治問題解決。

至於核四,我認為工程上的問題,終歸有工程的方式來解決。
http://www.taiwan-panorama.com/tw/show_issue.php?id=199658505076C.TXT&table=0&h1=6YCP6KaW6LKh57aT&h2=5YWs5YWx5bu66Kit
可以參考這篇文章,看看阿扁總統(我記得我看完這篇之後超佩服他的)如何整頓台北捷運,讓它恢復上線。

即便是蓋得亂七八糟的木柵線,還是有適當的方式;如果帽梁出現裂鏠,可以透過覆鋼板解決;對安全系統有疑問,可以不斷的進行測試;這一切都是風險與後果的評估。

以飛安來比喻的話,現在全球平均一天有80K航班在飛行,例如馬航事件的風險事實上是以百萬分之一的等級(甚至更小)在算的,因此我們假定搭飛機是很安全的。或許有人覺得拿飛安比核電,實在是打火機比手榴彈,我覺得只是風險層次不同,概念是一樣的,更高的風險,就要更高的安全規格。

從技術角度來說核四的安全風險是可以評估而最小化的,同時工程上也有檢測的方式,我認為這是我擁核甚至擁核四的論點。
圍阻體裡面出現保特瓶,可以打掉重建,只要檢測得到同樣工程強度。
你怕高鐵出軌,你可以先跑三個月試試;核四你怕它會爆炸,讓它先測試一年再用最低功率試轉三年呢?這樣餘熱發生危險的機率也小。

如果「假設」核電廠最終一定要爆炸,那我們現在就要把所有的核電廠停下來,任何技術的討論都沒有意義。就像如果我們認為飛機很危險,那現在就該停飛所有航班改搭客輪(你這樣說歲月號怎麼辦?)。

喔然後我知道我寫到這裡一定又要被罵了,先別急,我還沒說完。

上面這些內容有一個很重要的前提:信任。
我只談科技,但現實的工程能不能跟上設計?沒了這個,上面一切都是白講。
「陳椿亮將捷運局一切資料公開,並開放記者全程旁聽採訪,還要求同仁做百分之百的配合。陳椿亮心裡始終堅信,捷運是「真金不怕火煉」,希望大家有一個公平的對待,還捷運局一個肯定。」現在政府能做到這樣嗎?

從政府現實面來看,我認為核四已經無法運轉了。
http://www.ptt.cc/bbs/Gossiping/M.1399040614.A.79C.html

這一切都是信任問題,這個政府跟工程品質可信嗎?政府你拿什麼說服我工程品質可信,馬路嗎?你為什麼不去吃屎?現在政府做得最好的不就消波塊(誤)?
簡而言之,無論從生活經驗、新聞、流言蜚語,我們不相信政府的施工品質;何況還有一個常識上我們覺得工程品質(特別是馬路Orz)遠勝於我們的日本,儘管事實上日本對核安的要求在東日本大地震前是不及台灣的。
現實上我會支持反核團體持續對政府施壓,作更完善的安檢,把一切資料公開出來,讓全民去檢視、抉擇,每個人都有不同風險的接受線,也許我比別人低了一點,我對台灣的工程水準信心比較高,這沒什麼對或錯的問題。
但當核災的後果已經放到很大,已經到了風險必須小到幾乎達不到的境界,要通過進行商轉幾乎是不可能的事。

結語我會說:「陽光是最好的消毒劑」
核四問題怎麼解?球在政府手上,陽光照亮核四,核電才有希望。
偏偏台灣政府一直覺得嘴砲才是最好的消毒劑,結果口水裡一堆細菌,愈講愈髒。
或許這是我送給核四的訃聞?

--

好不容易打完,我要睡了。
是說我在打這篇之前,隱約覺得我寫過核四相關文章,一查之下果然有lol。
http://yodalee.blogspot.tw/2013/03/blog-post.html
這個現在拿出來是老調重彈,我也覺得最近大家已經不會再亂轉貼奇怪的嘴砲了,大概是這篇文有它的效用(自我感覺良好中)。

參考資料:
1. 全球航運:
http://www.fdsm.fudan.edu.cn/emba/secondclass/Show.aspx?ID=ada40770-2fee-43c2-83b5-beb907f6fd0c
好啦其實這個資料不算太重要,事實我們對一些事都有奇怪的連結:
例如最近實驗室的同學與學長們正在準備去美國旅遊參加conferencepaper(註:好好喔T_T),選飛機的時候,有像是華航、長榮、Delta(?)之類的選擇,學長一口就咬定不要華航,原因是華航曾有「四年大限」的都市傳說,還外加那霸空港的意外。
好但是最後一次四年大限已經是12年前的事,那霸空港意外證實是波音的問題,可是大家還是不搭華航(何況長榮好像還比華航貴),潛意識裡,華航的意外造成現在對華航飛安的不信任。
說福島爆了所以核四也會爆,某種程度跟這樣的連結差不多,直接無視兩個核電條件有多不同。