法學新論：從產業全球化佈局觀點論我國研發成果管理之法制政策
本文為「經濟部產業技術司科技專案成果」
「自動駕駛車(self-driving car)」一般而言係指於汽車安裝感測器(sensors)以及軟體以偵測行人、腳踏車騎士以及其他動力交通工具，透過控制系統將感測到的資料轉換成導航道路，並以安全適當的方式行駛。其目前可分為兩類：「全自動駕駛車(full autonomous)」以及「半自動駕駛車(fully autonomous)」，全自動駕駛車係指可於指定地點出發後不需駕駛人(driver)在車上而到達目的地者之謂。全自動駕駛車又可為「用戶操作(user-operated)」與「無人駕駛車(driverless car)」。 目前包含賓士(Mercedes)、BMW、特斯拉(Tesla)等公司均預期於不久將來會發布一些具備自動駕駛特徵的車種，科技公司如Google亦對於自動駕駛車的科技研發不留餘力。 而從2012年開始，美國有17州以及哥倫比亞特區便開始在討論允許自動駕駛車上路的相關法規，而只有加利福尼亞州(California)、佛羅里達州(Florida)、內達華州(Nevada)及華盛頓哥倫比亞特區(Washington, D.C.)有相關法律的施行，其他州則尚未表態。而大部分的州傾向認為應由人類來操控(operating)汽車，但對於具體上到底有多少比例之汽車任務需由人類操控而多少比例可交由機器則尚有模糊空間。而是否肯認「人工智慧操控」符合法規之「人類操控」亦不明朗。不過在法律存有這樣灰色地帶時刻，Google搶先於加利福尼亞州進行測試其自動控制系統，期望之後於自動駕駛車逐漸上市普及後能搶占商機。
澳洲聯邦法院判決藥品仿單受著作權保護澳洲聯邦法院近日在Sanofi-Aventis Australia Pty Ltd與Apotex Pty Ltd一案中([2011] FCA 846)，首次針對記載藥品資訊的仿單著作權侵權問題進行處理。法院判決Sanofi的Leflunomide藥品仿單含有Sanofi員工相當的知識與判斷，係Sanofi員工的共同著作，受到著作權的保護。法院並進一步判決Apotex的Leflunomide藥品仿單重製了Sanofi 的Leflunomide藥品仿單的重要部分，在係爭案件中，亦無法推斷出有默示的授權，因此判決Apotex侵犯了Sanofi的Leflunomide藥品仿單的著作權。 儘管藥品仿單的複雜問題目前仍備受爭議與討論，澳洲將在醫療物品修正法案(Therapeutic Goods Legislation Amendment (Copyright) Act 2011)中，針對相關問題加以釐清。前述修正案針對1968年著作權法(Copyright Act 1968)新增44BA條，該條項賦予在1989年醫療產品法(Therapeutic Goods Act 1989)25AA條款下有關醫藥產品資訊的合理使用範疇，明確規範包括供給、重製、發行、散佈/傳播(communicating)、改作等利用全部或部分醫療藥品資訊的行為不侵害產品資訊的著作權。
美司法部對Google書籍搜尋和解方案是否涉嫌壟斷展開美司法部於2008年介入Google與Yahoo網站上進行的搜尋動作提供相關廣告的合作案後，再次針對Google公司的網路版圖擴張動作，是否造成阻礙公平競爭採取調查行動，這次的目標是Google與書籍作者與出版商之間的圖書、文章數位化和解協議。 事實上Google 去年已與美國書籍作者與出版協會取得和解共識，前者願支付 1.25 億美元和解金，後者則撤銷其違反著作權的指控。但「無主」(orphan)的著作物，像是絕版書或不明著作的書籍作者必須在5月5日最後期限前選擇退出Google的計畫，否則就會被納入和解案。 不過，有七位作者上周向法院要求把5月5日截止期限再延長四個月，理由之一是提議的和解案太複雜。為讓Google有更多的時間，與其它作者商議和解協議，美國紐約聯邦法庭已將和解的期限延至 9 月4 日。Google表示會再花六十天的時間找到作者，並說服他們就Google線上書籍搜尋服務一案達成和解。如果Google的和解計畫順利完成，在其「Google Book Search service」搜尋服務中，將可找到數百萬件的作品。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。