OECD氣候行動監測與科學技術之挑戰

  經濟合作與發展組織(Organisation for Economic Co-operation and Development,簡稱OECD)於2022年11月7日發布《2022年氣候行動監測 幫助各國邁向淨零碳排》(The Climate Action Monitor 2022 Helping Countries Advance Towards Net Zero),係由國際氣候行動計畫(International Programme for Action on Climate,簡稱IPAC)團隊撰擬,提供全球氣候行動的重要見解。

  IPAC提出之分析方法係本於OECD與聯合國環境規劃署(United Nations Environment Programme,簡稱UNEP)的「壓力–狀態–回應」(Pressure-State-Response,簡稱PSR)環境指標模型。與政策回應相關的潛在限制與障礙,可區分為四個關鍵領域:1、治理:有效率的執行脫碳政策或需有新的治理框架;2、關鍵材料:脫碳政策需使用的關鍵材料如銅、鋰等;3、技能、技術與創新:回應氣候變遷政策需個人和機構有新的能力和技術;4、財政:以政策回應需有充足的資金。

  推動淨零在科學技術上面臨的挑戰為關鍵材料的應用。相較於化石燃料,綠能技術需更多的材料;特別是應用於電力系統的銅和鋁,或應用於電池的鋰、鈷和石墨。稀土對於風力發電機、電動與混合動力汽車、行動電話、電腦硬體、平面顯示器和電視機為重要材料。惟此些關鍵材料的取得集中於極少數的國家,以致於供應鏈易受單邊衝擊的影響,而使價格飆升,阻礙轉型。原材料占綠色技術大部分的成本,而緊張的材料市場可能會阻止對綠色技術的使用。氣候計畫與公告需考量關鍵技術的風險,實踐可信且穩定的淨零碳排,需於全球開發新的資源、新型的加工製程,與加速投資。並藉由新技術,與發展特定材料的回收鏈,以減緩對取得材料的依賴。

  OECD提出「福祉透視」(the Well-Being Lens)的流程,以協助各國確認與考量淨零轉型的優先政策。此過程的步驟為:1、預設若為運作良好的系統所能達成的成果;2、理解現行系統無法達成的原因,以及如何重組和設計系統;3、確認行動與政策對於改善系統運作具有潛力。

  本文同步刊登於TIPS網站(https://www.tips.org.tw

相關連結
※ OECD氣候行動監測與科學技術之挑戰, 資訊工業策進會科技法律研究所, https://stli.iii.org.tw/article-detail.aspx?d=8908&no=64&tp=1 (最後瀏覽日:2026/09/16)
引註此篇文章
你可能還會想看
APPLE以違反DMCA法案追訴Psystar

  根據美國北加州聯邦地方法院之資料公佈,APPLE已於上週對“Mac Clone”(克隆機)廠商PSYSTAR追加控訴,指控PSYSTAR侵犯了APPLE的著作權和商標權,同時,亦違反了美國1998年通過之數位千禧年著作權法(DMCA - Digital Millennium Copyright Act)的規定。APPLE表示,尚有其他廠商涉及本案,但APPLE仍未公佈其他涉案廠商名單。   PSYSTAR總部位於美國佛羅里達州,今年4月其推出了安裝APPLE Leopard OS X作業系統的低價個人電腦。此“Mac Clone”(克隆機)標準版售價為399美元,高階版售價999為美元。繼今年7月APPLE對PSYSTAR提起法律訴訟後,11月26日又針對PSYSTAR推出的“Mac Clone”(克隆機)追訴其侵犯了APPLE著作權和商標權。   今年8月份,PSYSTAR曾反控APPLE,宣稱APPLE把Mac機種之硬體和Mac OS X作業系統實行捆綁銷售(Tying),已明顯涉及不公平競爭,並違反美國反壟斷法相應條款。APPLE於9月份已要求法院認定PSYSTAR該項反訴無效。該起訴訟的主審法官威廉•阿爾薩普(William Alsup)於11月18日已作出裁決,認定PSYSTAR對APPLE的反訴無效。   APPLE的律師表示,該公司已握有充足之證據,因此決定對PSYSTAR提出其違反DMCA法案的追加指控。但APPLE的律師沒有對此證據加以具體說明,僅表示該項新指控與PSYSTAR的產品和市場行銷活動有關。   按照原定訴訟程序,APPLE起訴PSYSTAR的訴訟預計將於2009年11月09日開庭審理,PSYSTAR和APPLE雙方必須於2009年08月20日之前向法院提交一份描述兩造觀點和權利的說明。

歐盟傳統作物與基因改造農作物之共存門檻制度受到歐洲法院的挑戰

  歐洲法院(European Court of Justice)於2011年9月6日作出一項指標性的判決,係針對蜂蜜或食物補充品(Food Supplement)中,若其花粉成分受到基因改造作物之污染,則無論該污染是有意或無意所造成者,未經審核前均不得任意販售。據此,蜂蜜或食物補充品的生產者得就因不得販售所產生之損失向污染源或政府求償。   該案原為德國的養蜂人認為其生產之蜂蜜中的花粉受到鄰近距離五百公尺的基因改造農作物試驗之污染,而該試驗即為巴伐利亞政府所核准之基因改造農作物試驗(1998年EU核准的MON 801 maize),故而對巴伐利亞政府提出求償。原德國法院在不能確定蜂蜜是否涵蓋在基因改造規範的情況下,轉而尋求歐洲法院的判決。   該判決等於是挑戰歐盟現有的對於傳統作物及基因改造作物共存的政策與法規(GMO, Co-Existence),歐盟就該共存的門檻標準設定在0.9%,若產品含基因改造成分0.9%以上,需標示為基因改造產品,惟標示為基因改造食品對於傳統農作物之種植可能帶來銷售上的不利。而在共存門檻之下,含有基因改造成分的傳統農作物還是有可能因含有基因改造的成分而影響銷售並帶來損失;又因在共存門檻之下,作物含有基因改造成分是無法向政府或是來源求償的。另一方面,該判決亦影響出口蜂蜜至歐盟的國家,如大量生產蜂蜜且核准種植基因改造作物的阿根廷等國家。   對於基因改造食品採取保守態度的歐盟,近年來有意將是否禁止基因改造農作物以及共存門檻的比率下放給成員國自行決定,在成員國間形成兩極化的意見,而該項提案目前雖已經歐盟議會背書,但尚未由各成員國通過。這樣的判決令共存門檻的制度形同具文,且可能會使更多國家傾向禁止種植基因改造農作物,而不利於基因改造科技的研發。

英國「文化、媒體及體育部」宣布了電信管制機關Ofcom的改革

  英國「文化、媒體及體育部」(Department for Culture, Media and Sport,DCMS)於2010年10月14日宣布關於19個公共部門的改革或廢除的政策,目的在增加政府公共服務的透明度與負責度。這些政策也包含針對電信管制機關Ofcom的改革方案。   針對Ofcom擬議的改革如下:修訂Ofcom每五年檢討公共廣播服務的責任,改由部長決定檢討的時機與範圍。允許Ofcom能有彈性的改變其機關結構,但須經過部長批准。廢除Ofcom促進訓練發展機會與提供公平機會的責任。改變Ofcom對區域頻道Channel 32網路安排之檢討,由年度檢討轉變為保留由Ofcom評估是否需要檢討。修訂Ofcom每三年審查媒體所有權的責任,回歸由部長決定是否檢討。取消對公共廣播服務者需提供年度節目規劃政策資訊的要求。修訂Ofcom對於Channel 3 與Channel 5的執照控制權變更的自動審查責任。允許Ofcom向ITU收取衛星申請費用。而在政府組織改革中,也計畫將郵政主管機關Postcomm合併至Ofcom,並隨之修訂其義務與權限。由這些改革方案來看,主要的作用在於修正或限制部分Ofcom的責任,以將政策制訂的權限回歸DCMS部長,減少不必要的花費與提高行政效率,後續效應值得觀察。

歐洲議會全體會議投票通過《資安韌性法》草案,以提高數位產品安全性

歐洲議會於2024年3月12日全體會議投票通過《資安韌性法》(Cyber Resilience Act)草案,後續待歐盟理事會正式同意後,於官方公報發布之日起20天後生效。該草案旨於確保具有數位元件之產品(products with digital elements, PDEs)(下簡稱為「數位產品」)具備對抗資安威脅的韌性,並提高產品安全性之透明度。草案重點摘要如下: 一、數位產品進入歐盟市場之條件 課予數位產品之製造商及其授權代理商、進口商與經銷商法遵義務,規定產品設計、開發與生產須符合資安要求(cybersecurity requirements),且製造商須遵循漏洞處理要求,產品始得進入歐盟市場。 二、數位產品合規評估程序(conformity assessment procedures) 為證明數位產品已符合資安及漏洞處理要求,依數位產品類別,製造商須對產品執行(或委託他人執行)合規評估程序:重要(無論I類或II類)數位產品及關鍵數位產品應透過第三方進行驗證,一般數位產品得由製造商自行評估。通過合規評估程序後,製造商須提供「歐盟符合性聲明」(EU declaration of conformity),並附標CE標誌以示產品合規。 三、製造商數位產品漏洞處理義務 製造商應識別與記錄數位產品的漏洞,並提供「安全更新」(security updates)等方式修補漏洞。安全更新後,應公開已修復漏洞之資訊,惟當製造商認為發布相關資訊之資安風險大於安全利益時,則可推遲揭露。 四、新增開源軟體管理者(open-source software steward)之義務 開源軟體管理者應透過可驗證的方式制定書面資安政策,並依市場監管機關要求與其合作。當開源軟體管理者發現其所參與開發的數位產品有漏洞,或遭受嚴重事故時,應及時透過單一通報平臺(single reporting platform)進行通報,並通知受影響之使用者。

TOP