「達文希密碼」的著作權爭議

  「聖血及聖杯」作者邁可貝奇及理查李伊於今年二月在英國高等法院對暢銷書「達文西密碼」出版商「藍燈書屋」(Random House)提出訴訟,主張「達」書作者丹布朗抄襲「聖」書中的若干想法(ideas)及主題(themes),包括其研究多年的「耶穌血脈理論」,因而侵害其著作權。


  被告律師對於原告所提之控訴表示,「聖」書中的若干創意在本質上具備高度普遍化特質,無法成為著作權保護之客體。而原告律師亦強調,本案爭論重點並不在於「忽視他人創意成果」或是「獨佔想法或歷史事件」,主要是證明「達」書作者大量依賴「聖」書內容而完成「達」書。原告希望取得禁止令禁止「達」書使用「聖」書資料,此舉將迫使原訂今年
5月中旬由湯姆漢克主演之原著電影延後上映。


  著作權法之核心精神是保護「表達」,而非「想法」。對於同一題材之文學作品要區分何者屬表達,何者屬想法,並非易事。本案的出現僅是再次印證理論與實務之差距,而本案之後續發展亦值得繼續關注。

相關連結
※ 「達文希密碼」的著作權爭議, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=722&no=67&tp=1 (最後瀏覽日:2026/07/06)
引註此篇文章
你可能還會想看
墨西哥聯邦資料保護法生效

  墨西哥的聯邦資料保護法在二0一0年四月經墨西哥國會通過後,已於同年七月六日生效。這個新法旨在保護個人的隱私權並強化個人對自身資訊的掌控。與我國新近通過的個人資料保護法相同,墨西哥的這個新法所規範的範圍也包括了私部門對個人資料的蒐集、處理與利用。   在新法通過之後,原本的聯邦公共資訊近用機構(Federal Institute for Access to Public Information),亦擴張執掌並更名為聯邦公共資料近用及資料保護機構(Federal Institute of Access to Information and Data Protection)。在新制下,該機構將在原有負責事務外,另肩負起監督私部門就個人資料保護的相關事務。   此外,該法設計了一個雙重的監督機制:當資料的蒐集、處理或利用人,也就是所謂的資料控制者(Data Controller)出現可能違反聯邦資料保護法的狀況,將先由各相關部門的主管機關,例如主管經濟事務的機關或主管交通事務的機關來介入處理,而非由聯邦公共資料近用及資料保護機構立刻介入。

歐盟支付服務指令修正案(PSD2)於2016年1月12日生效

  2012年歐洲議會發表的綠皮書「邁向信用卡、網路以及手機支付的整合歐洲市場(Towards an integrated European market for card, internet and mobile payments)」,並進行廣泛的公眾意見徵詢,舉辦公聽會,最後決議進行現有歐洲支付法制架構的修正。歐盟支付服務指令修正案(revised Payment Service Directives, PSD2)於2013年7月由執委會提出,2015年10月歐洲議會通過,今年1月12日生效,預期英國、保加利亞、丹麥、德國、奧地利以及法國將會率先修正原有的支付服務法制完成轉換。產業界一致對於修正案表示歡迎,因為本次修正將會大幅提升支付創新應用的發展可能,尤其是行動支付。   PSD2之重大修正包含針對支付服務的內容作出修正,新增第三方支付服務提供人(third party payment service provider,簡稱TPP)為支付服務之內容(附件一第7項)。TPP的內涵為透過對於其它支付服務提供者的支付帳戶的存取,提供包含支付發動服務(payment initiation services)以及帳戶資訊服務(account information services)。依照第58條規定,TPP服務提供者具備下列義務: 1.確保支付服務使用者的個人化安全資訊不會被其它人取得。 2.以明確的方式向帳戶之支付服務提供者認證自己的身分。 3.不儲存支付服務使用者的敏感支付資訊或個人化安全憑證。   除此之外,PSD2明確將純粹的技術服務提供者排除於支付機構之範圍,無需適用支付服務指令。   PSD2亦授權EBA發布相關規定制定技術門檻,包含強力的客戶身分認證以及通訊資訊標準。

美國國家安全局發布「軟體記憶體安全須知」

  美國國家安全局(National Security Agency, NSA)於2022年11月10日發布「軟體記憶體安全須知」(“Software Memory Safety” Cybersecurity Information Sheet),說明目前近70%之漏洞係因記憶體安全問題所致,為協助開發者預防記憶體安全問題與提升安全性,NSA提出具體建議如下:   1.使用可保障記憶體安全之程式語言(Memory safe languages):建議使用C#、Go、Java、Ruby、Rust與Swift等可自動管理記憶體之程式語言,以取代C與C++等無法保障記憶體安全之程式語言。   2.進行安全測試強化應用程式安全:建議使用靜態(Static Application Security Testing, SAST)與動態(Dynamic Application Security Testing, DAST)安全測試等多種工具,增加發現記憶體使用與記憶體流失等問題的機會。   3.強化弱點攻擊防護措施(Anti-exploitation features):重視編譯(Compilation)與執行(Execution)之環境,以及利用控制流程防護(Control Flow Guard, CFG)、位址空間組態隨機載入(Address space layout randomization, ASLR)與資料執行防護(Data Execution Prevention, DEP)等措施均有助於降低漏洞被利用的機率。   搭配多種積極措施增加安全性:縱使使用可保障記憶體安全之程式語言,亦無法完全避免風險,因此建議再搭配編譯器選項(Compiler option)、工具分析及作業系統配置等措施增加安全性。

我國電子公文法制的最新發展

TOP