Jserv's blog

《十日談》與法律

雖然說從小就被迫接觸許多法律知識，但真正花時間涉獵，反倒是因為在花蓮空軍服役時，涉嫌觸及陸海空軍刑法所規範的犯罪行為 (細節就不提，人總是會犯錯)，自己的前程可能毀於一旦，茫然的我不知如何是好，只得故作鎮定地借了《陸海空軍刑法》閱讀，試圖釐清連帶的責任。後來很幸運地「脫逃」，也順利平安退伍 (當然多少仍因此事受到處分，不過我很高興，自己能在短短的一年多軍旅生涯，經歷這麼多變化)，但接下來的生活似乎與法律有很大程度的關聯性，最常碰到的就是軟體的授權與法律責任，特別是自由軟體與 "copyleft" 相關的。傍晚在 IRC 上才跟朋友討論到這個議題，又拜讀 [擺盪在兩個端點的Florence以及OSS] 一文有感，稍作紀錄。

之前因公事跟任職於中研院的 [Florence] 作了討論，我在往返的信件提到：

看到 "Florence"，讓我想到薄伽丘的《十日談》，我對於法律的認知，就好比《十日談》中描述人性軟弱、無助與焦慮一般，這議題在資訊產業缺乏充分的教育與工具使用、隨處可及的智慧財產權「陷阱」...

當時沒寫完，因為稍後就被抓去開會，今晚利用空檔補上。終其一生，文藝復興時期的薄伽丘著作豐富，長、中、短篇小說與詩集都遠近馳名，而對後世影響最大的，要算《十日談》，該小說集創作於 1348 到 1358 年間，背景是 1348 年的佛羅倫斯。當時歐洲流行黑死病，傳染迅速，以至於死屍遍地，居民莫不爭相遷移外地，而其中避居於佛羅倫斯郊外別墅的三個男人與七名女子就成為小說家筆下的主人翁：他們為了排遣遺世獨立的孤寂，相約每人每日都要分享一則故事，歷經十日，共有一百則故事，這也是小說名稱的由來。這種第三人稱的敘事方式，重新闡述了當時義大利生活的型態，也多少摻雜了薄伽丘自身的人文主義，書評不需要我多說，想必多數的朋友應該都對此名著相當熟悉。書中種種露骨的文字，卻相當真實地刻劃封建貴族的荒唐墮落與殘忍無道、市井小民又是何等軟弱、無助，與焦慮，而幾百年後的我，面對軟體與加諸其上的法律條文規範，又豈能不焦慮呢？[Florence] 回信道：

其實對於法律人來說，「法律」也是一個充滿陷阱的危險叢林...

軍旅生涯中，強迫自己研讀《陸海空軍刑法》，對現在有很大的幫助，我不時會參考 [中央法規]，也才讓我深深體驗，原來我們周遭有這麼多法規，任何小舉動都可能觸及法律責任。就算只當個長時間安身於辦公室的小小工程師，除了收信、看新聞、開會，就只剩下 coding 了，這麼單純的工作背後，看起來沒什麼風險 (過勞死除外)，但真正的危機往往難以衡量。首先，是專利議題，一個關鍵專利足以讓 SiS 這樣具規模的電子產業，延遲出貨，造成巨大的財務損失，其訴訟官司更在台灣電子產業成為經典案例，製程、模具、半導體設計，與機構設計如此，充滿種種不確定性的軟體建設更是令人迷惘。以 Speech coding 來說，無論是國外或國內，都有一系列描述「基本方法」的專利限制，比演算法更含糊、影響更廣泛，或許哪天想到一個很棒的方法，用力去實做，花了好幾天 coding，還對於自己的方法沾沾自喜，等要出貨時，才發現早已有一系列的專利卡在那邊，到時候，是誰的問題呢？或許，我們會說：「我才沒有那個聰明才智，不會發明新東西，只拿現成的軟體來改，總行了吧？」而這，才是另一個大問題的開端。

以前唸書時，不同學科總有經典著作，比方說 Operating System 就有「恐龍書」，而 OpenGL 就有「紅皮書」，裡面的程式碼範例也被視為 public domain，亦即，只要是讀者，無論用什麼方式去「融會貫通」，那些 sample code 應用到讀者的專案，就是讀者的創作，以讀者的角度來說：「我買這些經典書籍，就是要學習到技術，這些 source code 對我有很大的助益，而我也依據這些基礎完成了軟體專案」，的確合情合理。不過，Richard Stallman 建立了 "copyleft" 的概念，並非對 "copyright" 或著作權作顛覆行動，而是提供一個邏輯上的規範，也就是基於軟體分享、軟體自由通行、軟體自由修改，以及讓軟體得以被賦予新的價值等概念，也透過這個概念，起草 GNU GPL 的軟體「契約」。全面性來說，這是一個很好的模式，然而，這種「附帶回饋責任」性的條款，也跟許多自(19)八零年代就蓬勃發展的軟硬體產業造成衝擊。以嵌入式系統來說，以前的工程師無論是什麼背景，可能開工沒多久，就得要自己寫 Monitor / Kernel / RTOS，硬體也是自己設計的，甚至還得負責整體的機構配線等，因為就是有那個需要。然而，處於分工與強調標準化的今日，這種現象已難以復見 (不過我有一位日本的朋友還在作這樣的工作，持續二十餘年)，人人琅琅上口的就是 "solution"，這個 "solution" 一詞很妙，跟 "answer" 不同，"solution" 似乎就是漫漫長夜的明燈，指引我們到出路，也因此，很多工程人員不問 "question"，也不想搞清楚 "question" 具體內容，就只關心 "solution"，"schedule" 芒刺在背，不得不用力推進。

隨著軟體的成長，以及 free / open source software 透過網際網路的累積與交互發展作用，各種經典的軟體都出現了，不僅有 bootloader、kernel、 C Library、Device driver、GUI system、Network stack、... 等傳統認知的軟體範疇，現在連 SPARC 工作站的 CPU core 也釋出其硬體 VHDL 原始設計，這裡不打算作深入介紹，反正在 Google 上隨便找都是一堆，bookmark 永遠整理不完。 這些的確是很吸引人的 "solution"，不僅容易取得 (不需簽署 NDA 或繁複的法律程序)，更是 royalty-free，簡單來說，就是「免錢」，然而，真是如此？現在 IT 產業的法律規範越來越多，記得我以前在光寶科技 (LiteOn) 服務時，第一天就得捧著厚厚一本的員工契約，一條又一條地檢視並同意，那份厚重的文件對員工所需肩負的責任，給了詳細的說明，這之中，資訊保密就是相當重要的。可以想見其他 IT 產業也差不多，如果專案中引用了 "copyleft" 發行的軟體元件，會有什麼影響呢？各種 software license 應該都有提到其適用對象，並且使用上的限制，與擔保的範疇，再來會提到像是專利互惠條款一類的附加規範。以我們熟悉的 GNU GPLv2 來說，想像成「病毒」就很容易理解：「歡迎使用，但重新散佈或修改也請分享 source code」，然而，GNU GPLv2 只是一種契約，試想一個情境：一個小小工程師，為了要解決技術上的問題，在 Google 上找到某某計畫已經有了很大的突破，於是加入原本的軟體設計中，這也讓開發時程得以獲得控制，但是，原本的軟體設計也因此被「感染」，成為不折不扣的 GPL'd software，工程師總是單純的，於是依據這個「GNU GPL 契約」，也將修改的部份分享出來，這是美事一樁，不過，進公司第一天就簽署的「員工保密契約」又該怎麼辦？後者的效力當然遠大於 GNU GPL，而且不謹慎處理的話，還可能因此丟掉飯碗，離職原因才不是「捍衛 GNU GPL」這種神聖的迫害性闡述，而是「涉嫌洩漏業務機密」一類的惡名。

之前發表 [再談自由軟體授權] 與 [簡報：自由軟體授權分析] 等系列的 blog entry，其實我本人是沒什麼高度意願想在這個議題著墨，但總會收到信件、電話，或者是法務人員親自來訪，所以只好稍作整理，交流指教是很歡迎，不過我心中的疑惑是：

這種問題，該問法律專家，怎麼跑來問我這個差點被軍法審判的人？

(按：儘管如此，我今年有規劃更新 slides，並且涵蓋如何對 GPL'd 軟體元件作模組化區隔，以及整理相關案例，希望我手頭的專案能早點結束) 雖然僅可能讓自己白天跟晚上的工作內容不相關，比方說白天改善 speech codec 的效能，晚上設計 virtual machine，假日再來作雜項的技術顧問，不過這樣實在很難兼顧，最重要的是，潛在的法律問題是很麻煩的。我習慣用 Linux 作軟體開發，就算 target 上面是 WinCE，我也可以用 Debian 上的 toolchain 來作 prototype，但很多 routines 其實怎樣寫都會差不多，不知不覺白天在公司的創作，就會出現於晚上，或者給其他家公司的顧問工作中，我該如何釐清？該如何跟老闆與客戶澄清呢？我花了很多時間作這些非技術的溝通，有時候只好如之前的 blog [為何要醉 coding] 一般，回家趕快用酒精麻痺自己，買醉後，我才得以忘記這些「包袱」，現實的問題太多、太多了，其實我自己就深受軟體授權、軟體專利，以及相關的法律條文所困，又怎能協助其他人呢？ *笑*

如果《十日談》有機會改版，請把我這個無聊男子的憂鬱、恐懼，以及茫然的故事寫進去。
由 jserv 發表於 March 12, 2006 09:33 PM