美國上訴法院認為《Oh, the Places You’ll Boldly Go!》即使混搭了《Star Trek》角色元素 但並未批判蘇斯博士企業之原著而缺乏轉化性、非屬著作權之合理使用
美國聯邦第九巡迴上訴法院於2020年12月針對繼承知名美國兒童繪本暢銷漫畫家蘇斯博士（Dr. Seuss）豐沛創作智財權之蘇斯博士企業（Dr. Seuss Enterprises，後稱原告）指控ComicMix公司及其三位創作成員（後稱被告）侵犯其著作權與商標權一案，作出認定被告侵害原告之著作權判決。
原告指出被告儘管混搭了《星艦迷航記》（Star Trek）之角色元素而提出《Oh, the Places You’ll Boldly Go!》（後稱系爭創作），然而實質上卻抄襲了蘇斯博士於1990年所創作的《Oh, the Places You'll Go!》（後稱原創作），並將該系爭創作於募資平台Kickstarter上籌措出版經費；在2019年3月一審判決中，被告宣稱其以戲謔方式呈現該系爭創作而被美國加州南區聯邦地方法院所採認，即該系爭創作具轉化性（transformative）而屬於著作權之合理使用，為此原告上訴至美國聯邦第九巡迴上訴法院。
上訴法院之判決主要根據美國著作權法第107條合理使用之四項判斷原則，該系爭創作僅僅呼應原創作而未對其進行嘲諷，且亦未增加任何新的表達、意義或訊息，因而認定該系爭創作並不具轉化性且無疑地將該系爭創作進行商業性使用，此外戲謔手法必須在有對受著作權所保護之創作進行批判或評論的情況下才會成立。其中，第三項要素「所利用之質量及其在整個著作所占之比例」為判決之關鍵所在，以量而言，將近百分之六十原創作被該系爭創作所複製，就質而論，該系爭創作竊取了原創作之核心；針對第四項要素「利用結果對著作潛在市場與現在價值之影響」，也因為未具轉化性與商業性使用而實質傷害原創作之市場價值，因而推翻一審判決認定系爭創作侵害原創作之著作權。
至於商標權侵害部分，儘管原創作具獨特品牌字體與創作風格，但上訴法院認為該些獨特風格不應該限制其他創作者之藝術表現，在權衡系爭創作之表達詮釋且未明確誤導消費者該系爭創作之來源，最終駁回原告商標侵權之主張。
「本文同步刊登於TIPS網站（https://www.tips.org.tw ）」
龔芳儀
專案經理 編譯整理
1.Ashley Cullins, Dr. Seuss Enterprises Wins Appeal In Dispute Over 'Star Trek' Mash Up, THE HOLLYWOOD REPORTER, Dec 18, 2020, https://www.hollywoodreporter.com/thr-esq/dr-seuss-enterprises-wins-appeal-in-dispute-over-star-trek-mash-up (last visited Mar 22, 2021)
2.Daniel Victor,‘Star Trek’ and Dr. Seuss Mash-Up Not Protected, Court Rules, THE NEW YORK TIMES, Dec 21, 2020, https://www.nytimes.com/2020/12/21/business/dr-seuss-star-trek-comicmix.html (last visited Mar 22, 2021)
3.Sarah Bro, This Mashup Is Not a Place You’ll Go – Seuss Copyright Will ‘Live Long and Prosper’, THE NATIONAL LAW REVIEW, Jan. 7, 2021, https://www.natlawreview.com/article/mashup-not-place-you-ll-go-seuss-copyright-will-live-long-and-prosper (last visited Mar 22, 2021)
德國聯邦內政部繼與德國聯邦經濟暨能源部與交通暨數位基礎設施部共同擬定之「數位議程2014 - 2017」(Digitale Agenda 2014 – 2017)政策裏，於本年8月19日提出資訊科技安全法(草案)(IT-Sicherheitsgesetz)。該草案的提出目的為保障德國公民與企業使用的資訊系統安全，特別是在全國數位化進程中，攸關國家發展的關鍵基礎設施。德國內政部長de Maizière在新聞發表會上，宣稱要讓德國成為全球資訊科技系統及數位基礎設施安全的先驅與各國的模範。除外，亦欲藉此強化德國資訊科技安全企業的競爭力，提升外銷實力。 該草案的主要對象係關鍵基礎設施營運者(Kritische Infrastrukturbetreiber)，例如在能源、資訊科技、電信、運輸和交通、醫療、水利、食品、金融與保險等領域的企業。「關鍵基礎設施」的定義並未涵蓋德國聯邦政府部門之間使用的數據通信系統。不過，究竟係在這些基礎設施領域的哪些企業該受到資訊科技法的約束，德國內政部將陸續與各相關部會研討後再以行政法規的方式明確表列出來。 關鍵基礎設施企業必須採取適當的保護措施以保障關鍵基礎設施的正常運行。所採取的保護措施可符合同業或同業公會裡所認可的最新資訊安全標準，且得符合一定的付出成本比例。不過衡量標準，最後還是得由德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)〉做認定。上述之企業需兩年內完成安全防護措施的設置。為防止電信系統非法入侵，該草案也修增德國電信法(Telekommunikationsgesetz)為施予電信業者更高的資訊安全防護標準。針對網際網路服務提供者(Internet Service Providers, ISP)也特別施加設置防範駭客攻擊的尖端防護措施義務。 關鍵基礎設施業者的資訊安全系統均須透過德國聯邦資訊安全局(Bundesamt für Sicherheit in der Informationstechnik, BSI)每兩年定期審核，若沒通過則會被要求依德國聯邦資訊安全局的標準去處裡該安全漏洞。 若是上述業者的資訊安全系統有受損，並且可導致關鍵基礎設施的故障或損毀，該企業需通報德國聯邦資訊安全局，且該記錄可匿名化。但是，若是因駭客攻擊直接導致關鍵基礎設施的故障或損毀，該企業則需立即通報德國聯邦資訊安全局，不可匿名。
經濟部技術處研究機構智慧財產管理制度評鑑與台灣智慧財產管理規範(TIPS)驗證內容比較 Google個資隱私權政策違反歐洲資料保護指令，六國將聯合採取法律途徑2012年3月Google將世界各地總共60個相異的個人資料隱私權政策統一後，即受到歐盟個人資料保護機構「第29條工作小組」的關注，該小組認為Google修訂後的個人資料隱私權政策違反歐洲資料保護指令（European Data Protection Directive (95/46/CE)），將難以讓使用者清楚知悉其個人資料可能被利用、整合或保留的部分。同時，Google亦可能利用當事人不知情的情況下，大量利用使用者個人資料。因此，2012年10月歐盟要求Google在4個月內對該公司的個人資料隱私權政策未符歐盟規定者提出說明，惟至今Google仍無回應。因此，歐洲6個國家，包括法國、德國、英國、義大利、荷蘭及西班牙的個資監管機構，將聯合審視Google的個人資料隱私權政策是否違反各國的法律，並依據各國法律展開後續措施，如鉅額罰款等。法國之資訊自由國家委員會（Commission nationale de l'informatique et des libertés，簡稱CNIL）率先表示，若Google於4月11日前未改善其資料隱私權政策，法國將首先採取法律行動。然Google對此僅簡單回應，表示其資料隱私政策尊重歐盟的法律，且可以讓Google提供更簡單、更有效率的服務。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。