2021年4月26日,歐盟商標協會(European Communities Trade Mark Association,以下簡稱ECTA)針對3D列印設計保護修法方向,向歐盟提交一份立場意見書(position paper)。歐盟自1998年發布《設計指令》(Directive 98/71/EC on the legal protection of designs)及2002年發布《設計規則》(Council Regulation(EC) No 6/2002 on Community designs)以來,已多年未進行修正;為了能對設計提供更有效的法律保護,歐盟從2018年起開始進行修法的公眾諮詢,並於2020年11月提出修法評估報告。
ECTA一直以來都很關注3D列印技術發展涉及的智慧財產議題,在意見書中列出了修法時應納入評估的重點。例如ECTA指出,雖然3D列印所使用的CAD模型檔案僅是列印過程中的媒介,檔案本身不能受到設計法律的保護,但檔案中包含了設計藍圖及其設計特徵,為了讓以數位形式呈現的設計能受到保護,建議應考慮修改《設計規則》第3條(b)及《設計指令》第1條(b)中對於產品(product)的定義,將CAD模型檔案及其他任何含有以數位形式呈現設計的物件(items)也納入產品的定義之中。
其次,ECTA認為應針對任何明知有侵權事實,但仍提供幫助的行為人課予輔助侵權責任(contributory infringement),以提供設計權人更有效的武器來捍衛自身權利。如行為人未經設計權人同意,自行利用3D儀器掃描物體,根據所得數據製作成CAD模型檔案,並將該CAD模型檔案提供給直接侵權人時,應成立輔助侵權。
最後,ECTA認為目前沒有針對3D列印技術制定專法的必要,僅需要在現行智財法律體系中進行修法調整即可,以避免法律體系過於複雜。
根據國際間重要農糧組織ISAAA(International Service for the Acquisition of Agri-Biotech Applications)所公布的2004年統計報告,全球基改作物栽種面積已達八千一百萬公頃,在2003年僅有六千七百萬公頃,成長幅度高達20%,尤其是在開發中國家。菲律賓是亞洲第一個支持商業化生產基因改造食物的國家,從2000年起即開始商業交易基因改造作物。由於其所研發之轉殖”IR-72”稻米品種栽培並不普遍,也未被消費者、農夫及麵粉業者廣泛地接受,因此不合適商業化生產,雖然菲律賓嘗試其他較受歡迎的品種來進行基改轉殖,但迄今尚未成功。 基於基因稻米對於環境安全和人體健康所帶來的影響是無法預知的,綠色和平組織抗議菲律賓政府加速推動生技農作物的計畫。菲律賓所面臨的挑戰不單僅是綠色和平的抗議,另一個因素因為氣候的不穩定而影響了稻米的產量,今年生產量僅148萬噸,距離目標?151萬噸,因此仍需仰賴進口稻米來彌補這不足的差距。 菲律賓稻米研究中心執行長Leo Sebastian認為,基改稻米並不是解決稻米供應不足的唯一方式,引介栽種高生產量的稻米品種或者改善灌溉系統等都是可行的方式。
商標權人的好消息—歐盟法院判決巴黎萊雅(L’Oreal)勝訴歐盟法院(European Court of Justice; 簡稱ECJ)於2009年6月18日判決,確認法國化妝品公司- 巴黎萊雅(L’Oreal SA)之競爭廠商-Bellure NV(簡稱Bellure公司) 有侵害巴黎萊雅之商標權,此一判決對於刻意仿冒之廠商予以重擊,也更擴大著名商標權人的商標保護範圍。 Bellure公司所販售及製造的香水,係仿似巴黎萊雅所製造香水的味道、瓶身及包裝,且更以”smell-a-like”的商品價格比較表做為廣告宣傳,藉由「搭便車」的方式推銷Bellure之產品。 歐盟法院認為,縱使Bellure的廣告宣傳及產品本身,並未直接和巴黎萊雅的產品產生商標混淆誤認的可能,且並未對巴黎萊雅造成直接的損害,但Bellure如此「搭便車」行銷自己產品的方式,確實是以不正當的廣告方式獲取不公平的利益,並銷售自已的產品。 本案將使商標權人對於日漸複雜的侵害類型獲得保障,如:仿冒品的販售及網路銷售等;此外,對於產品在做宣傳時也要小心使用比較性的文字(如:僅做產品性質差異的比對而非產品價格的比對),以免侵害他人商標權。
開放生物技術淺析 美國國家安全局發布「軟體記憶體安全須知」美國國家安全局(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)、工具分析及作業系統配置等措施增加安全性。