歐盟法院(Court of Justice of the European Union, CJEU)於2018年11月13日針對食品味道是否受著作權保護做出判決,其起因於荷商Levola Hengelo BV (“Levola”)認為同屬荷商之Smilde Foods BV (“Smilde”)所生產與銷售的起司“Witte Wievenkaas”,與Levola的起司產品“Heksenkaas”味道相同,因而控告Smilde侵害其“Heksenkaas”起司味道的著作權。 本案Levola於荷蘭地方法院中主張:食品味道著作權的定義,是指食用食品所產生之味覺整體印象,包括食品於嘴巴的口感,且該食品味道是製造者基於自身知識所創造。Levola並提出2006年6月16日荷蘭最高法院於原則上認定香水味道具有著作權的判決來支持其論點。 然而歐盟法院於本判決中指出,如果食品味道要受到著作權保護,那就必須符合「協調資訊社會下之著作權及相關權利指令」(Directive 2001/29/EC of the European Parliament and of the Council of 22 May 2001 on the harmonisation of certain aspects of copyright and related rights in the information society)(下稱2001/29/EC指令)對於著作(works)的定義,意即該著作應滿足原創性的要求,與著作能藉由精準並客觀的表達方式來識別。 係以,就本案所爭執之起司味道是否具有著作權,歐盟法院認為:因起司味道取決於消費者的味覺,其屬主觀且可變的,此缺乏精確性與客觀性,故並非2001/29/EC指令所認定之著作而受著作權保護。 不過讓人關注的是,歐盟法院特別於本判決中提到:在目前科學發展狀況下,尚無法透過一些技術或手段準確並客觀的辨識食品的味道,並就該味道與其他同類產品做區隔,所以在整體綜合考量下,才排除食品味道受著作權的保護。 基此,如果在未來科技能準確並客觀區別各種食品味道的時候,歐盟法院是否會承認食品味道符合2001/29/EC指令對於著作的定義,而讓其受到保護,此或許值得期待。
簡介人工智慧的智慧財產權保護趨勢近期人工智慧(Artificial Intelligence, AI)的智慧財產權保護受到各界廣泛注意,而OpenAI於2023年3月所提出有關最新GPT- 4語言模型的技術報告更將此議題推向前所未有之高峰。過去OpenAI願意公布細節,係由於其標榜的是開源精神,但近期的報告卻決定不公布細節(如訓練計算集、訓練方法等),因為其認為開源將使GPT- 4語言模型面臨數據洩露的安全隱患,且尚有保持一定競爭優勢之必要。 若AI產業選擇不採取開源,通常會透過以下三種方式來保護AI創新,包括申請專利、以營業秘密保護,或同時結合兩者。相對於專利,以營業秘密保護AI創新可以使企業保有其技術優勢,因不用公開技術內容,較符合AI產業對於保護AI創新的期待。然而,企業以營業秘密保護AI創新有其限制,包含: 1.競爭者可能輕易透過還原工程了解該產品的營業秘密內容,並搶先申請專利,反過來起訴企業侵害其專利,而面臨訴訟風險; 2.面對競爭者提起的專利侵權訴訟,企業將因為沒有專利而無法提起反訴,或透過交互授權(cross-licensing)來避免訴訟; 3.縱使企業得主張「先使用權(prior user right)」,但其僅適用在競爭者於專利申請前已存在的技術,且未來若改進受先使用權保護之技術,將不再受到先使用權之保護,而有侵犯競爭者專利之虞,因此不利於企業提升其競爭力。 綜上所述,儘管AI產業面有從開源轉向保密的傾向,但若要完全仰賴營業秘密來保護AI創新仍有其侷限,專利依舊是當前各企業對AI領域的保護策略中的關鍵。 本文同步刊登於TIPS網站(https://www.tips.org.tw)
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。