歐洲法院2017年12月認定Uber是運輸服務業
巴塞隆納計程車工會認為Uber未受西班牙運輸服務業相關法令管制，而有違反公平競爭之虞，因此向西班牙巴塞隆納3號商事法院提起訴訟。3號商事法院認為有必要進一步釐清Uber之商業模式究竟是否為歐盟法令下之運輸服務業或資訊服務業，亦或兩者均是。這將影響歐盟內部市場指令和電子商務指令之涵蓋範圍，從而決定Uber是否有違反競爭法。
為此，歐洲法院在2017年5月做出先行裁決後，於同年12月做出判決，認定Uber之性質是運輸服務業，因此排除前述指令之適用，應接受各國運輸服務業相關法令之要求，否則違反公平競爭。法院觀點認為縱然其商業模式看似乘客與駕駛之間為自由選擇之連結。然而，Uber提供的平台是這個連結不可或缺的關鍵以外，對於運輸服務的提供，包括價格、車輛、駕駛的選擇具有決定性的影響力。此外，Uber藉由組織這樣的運輸服務來獲取利潤本身就涉及了運輸服務的直接提供。所以Uber整體服務的主要組成部分必須被視為以運輸服務構成，不應被分類為資訊服務。
本文為「經濟部產業技術司科技專案成果」
林冠宇
主任 編譯整理
- Case C-434/15, Asociación Profesional Elite Taxi v. Uber Systems Spain SL, http://curia.europa.eu/juris/document/document.jsf;jsessionid=9ea7d2dc30dc4bb1e92359bd4e7aac5fbb859de8c5b3.e34KaxiLc3qMb40Rch0SaxyNaN10?text=&docid=198047&pageIndex=0&doclang=en&mode=req&dir=&occ=first&part=1&cid=94795 (last visited Jan. 30, 2018).
- Directive 98/34/EC, OJ 1998 L 204, p. 37. Directive 98/34/EC as amended by Directive 98/48/EC of the European Parliament and of the Council of 20 July 1998, OJ 1998 L 217, p. 18.
- Directive 2000/31/EC, OJ 2000 L 178, p. 1. |
- Directive 2006/123/EC, OJ 2006 L 376, p. 36.
科技法律透析第30卷第2期法規實務動態: 簡評歐洲法院認定Uber商業模式為運輸服務之判決
德國聯邦內政部繼與德國聯邦經濟暨能源部與交通暨數位基礎設施部共同擬定之「數位議程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)每兩年定期審核，若沒通過則會被要求依德國聯邦資訊安全局的標準去處裡該安全漏洞。 若是上述業者的資訊安全系統有受損，並且可導致關鍵基礎設施的故障或損毀，該企業需通報德國聯邦資訊安全局，且該記錄可匿名化。但是，若是因駭客攻擊直接導致關鍵基礎設施的故障或損毀，該企業則需立即通報德國聯邦資訊安全局，不可匿名。
英國不贊同歐盟新視聽媒體服務指令英國傳播、電信、科技及媒體相關領域業者及團體於 2006 年 4 月聯合發表一份意見書，反對歐盟提出的新視聽媒體服務指令（ Audiovisual Media Services Directive ）草案。同時英國政府也正關注這項草案並與其他會員國進行討論。 自 2005 年 9 月起，歐盟開始針對電視無國界指令（ Television without Frontiers Directive ）的修正進行討論。歐盟考慮將該指令修改為視聽媒體服務指令，擴大其規範範圍，使其包括各種與電視相似（ TV-like ）的服務，並將所有視聽媒體服務區分成線性（ linear ）及非線性（ no-linear ）服務，分別給予不同程度的管制。 不過英國有許多業者及團體對於這項新指令的制訂深表不贊同，其認為： (1) 就非線性服務（例如隨選視訊）而言，目前既有法規以及業者自律規範已足以保障消費者； (2) 線性及非線性的分類方式可能不適宜作為法律定義的基礎； (3) 新指令將可能阻礙新進業者參與市場的意願，甚至導致投資者轉向其他國家發展。所以希望透過連署，要求歐盟重新檢視這項新指令。
英國商業、能源及產業策略部提出新版「後2020智慧電表布建計畫」，以助於住家型智慧電表全面布建英國商業、能源及產業策略部（Department of Business, Energy and Industrial Strategy，以下簡稱BEIS）於2020年6月18日提出新版「後2020智慧電表布建計畫」（Smart meter policy framework post 2020，以下簡稱旨揭智慧電表計畫），擬於未來4年內全面布建住家型智慧電表，以助於住家型用電戶管理用電並進一步減低碳排放量。 依BEIS預估，布建後有可能助於節省住家型用電戶平均250英鎊之電費，並減少全國4千5百萬噸碳排放量。依旨揭智慧電表計畫，電表布建費用將由售電業負擔，售電業應盡其最大努力布建智慧電表，如售電業並未盡到此一義務，則恐將面臨高額罰鍰。同時，智慧電表之布建可以鼓勵消費者改變用電習慣，如鼓勵消費者於用電離峰時間對於電動載具進行充電，或者是設置（再生能源）發電設備用於用電高峰期間發電、饋電至電網。 從而BEIS旨揭智慧電表計畫，也是為BEIS於2019年1月提出智慧饋電保證（Smart Export Guarantee，以下簡稱SEG）鋪路。於SEG新政策下，BEIS將擬定一套不同於躉購制度之政策框架，使小型生產消費者（prosumer，此處係指可以自行生產電力之用電戶）所生產之綠色電力，可於此一政策框架之保障下，與售電業者議約，並將電力售予售電業者，以減輕英國政府預計於今年3月廢除躉購制度所帶來之衝擊。又依SEG新政策，小型生產性用電戶須設置有智慧電表，始受前開SEG新政策之保證，從而得以優惠之價格或條件將再生能源設備所產生之電力出售予電力供應事業主體。職是故，BEIS旨揭智慧電表計畫，實際上可謂與BEIS於2019年所提出SEG新政策相互搭配，以迎接後躉購制度時代之來臨。 對於智慧電表之硬體規格，依旨揭智慧電表計畫，第二代智慧電表（SMETS2）為其建置之核心。第二代智慧電表與第一代智慧電表不同之處在於，第一代智慧電表係以3G為通訊基礎，且不同電力供應事業主體所使用之系統相互間無法交流、並存，第二代智慧電表則以4G以上規格為通訊基礎，且不同電力供應事業係使用同一套系統。同時，智慧電表應盡量配置有「住家顯示系統」（In-Home Displays），使住戶可以透過視覺化之及時反饋方式，知悉現在住家內之能源使用情形以及相關電價狀況，從而進行改變用電習慣。同時，智慧電表之用電或饋電至電網之資訊，也應可以透過智慧電表傳輸至電力供應事業主體或交易市場，從而使電力供應事業主體可及時知悉用電戶之用電或饋電情形，從而及時做出反應。 對於智慧電表之建置程序以及資訊傳輸、保存安全性上，旨揭智慧電表計畫則要求應符合「智慧電表建置行為準則」（The Smart Meter Installation Code of Practice, SMICoP），從而用電戶可以在此一準則或框架下，對於自己之用電資料享有一定之掌握權限。
美國國家安全局發布「軟體記憶體安全須知」美國國家安全局（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）、工具分析及作業系統配置等措施增加安全性。