OSS V.S. Mircosoft風暴湧現 誰會是微軟時代的終結者
首先，昇陽（Sun）與Google簽下合作協議將推廣在網路上免費使用的文字處理軟體「OpenOffice」，兩家的合作對微軟OFFICE套裝軟體營收將會有很大的殺傷力。
再者，十月份正式推出的OpenOffice.org 2.0軟體，是第一套可穩定支援新XML開放文件格式（OpenDocument Format；ODF）標準的開放原始碼辦公室軟體。ODF是由OASIS（Organization for the Advancement of Structured Information Standards；結構化資訊標準推動組織）所制定的，採用XML儲存格式，具備共用性、跨平台等特性，並支援文書處理和資料庫等各種儲存格式。OpenOffice.org 2.0軟體還可以支援36國語言，又可在Microsoft Corp's Windows，Linux，Sun's Solaris等多家系統上執行 。
此外，美國麻薩諸塞州宣布自2007年起該州政府文件只能存成OpenDocument或Adobe的PDF兩種格式，因此該州所屬機關必須汰換不支援這2種格式的軟體，當然包括微軟OFFICE套裝軟體，如此一來微軟損失至少數百萬美元以上的商機。如果其他政府部門跟進，這不僅意味ODF的一大勝利，也將重挫微軟的龍頭地位。而Corel及Novell也重申支持OpenDocument格式。
此些舉動對於微軟的根基大業OFFICE套裝軟體可真是成心頭大患。
本文為「經濟部產業技術司科技專案成果」
歐盟法院（Court of Justice of the EU ,CJEU） 於2018年1月23日就Hoffman-La Roche and Others v Autorità Garante della Concorrenzae del Mercato案（Case C-179/16）作出先訴裁定（preliminary ruling）。本案涉及歐盟競爭法和藥品監管體系之間的相互影響。 案例事實為：羅氏藥廠的Avastin，原先為抗癌許可藥物，被臨床發現可用作治療老年性黃斑部病變（AMD），但並未經正式核准用於治療AMD，屬於仿單標示外藥物（off-label drugs）。而Lucentis係諾華藥廠一款獲得正式授權核准，作為治療 AMD的眼內注射藥物。 其中，諾華持有羅氏超過33%的股份，Avastin雖與Lucentis作用機理相似，但Lucentis價格卻相對昂貴，銷售方式由羅氏與諾華合作，諾華可從持股中間接獲得利潤。 兩家藥廠為了影響、降低Avastin的需求量及阻礙其分銷，雙方協議，對外聲稱兩種藥物含有不同活性成分，散布Avastin仿單標示外使用之安全性和有效性存在疑義的不實資訊。 2014年時，義大利競爭法主管機關（Autori tà Garante della Concorrenza e del Mercato, AGCM）認為羅氏和諾華兩大藥廠涉嫌藥品市場壟斷，違反歐盟運作條約（Treaty on the Functioning of the European Union, TFEU）第101（1）條，因而裁罰兩家藥廠。 羅氏和諾華不服裁罰，向義大利Lazio地方行政法院（Regional Administrative Court, Lazio）提起訴訟尋求救濟，遭到駁回；羅氏和諾華繼而向義大利國務委員會（Council of State）提出上訴，義大利國務委員會將此案提交歐盟法院，針對歐盟競爭法的解釋進行先訴裁定。 最後，歐盟法院認為兩藥廠之行為構成藥品市場的限制競爭，違反歐盟運作條約第101條之規定。 法院判決結果認為： 當上市許可藥物（marketing authorization, MA）和仿單標示外藥物皆適用治療同一疾病，只要它們具可替代性和兼容性，並且符合製造和銷售的規定，原則上屬於同一個相關市場。只要滿足其他要件，上市許可藥物並不當然決定相關產品市場的範圍。 非競爭者之間的許可協議可能符合歐盟競爭規則：歐盟法院闡述，這種傳播誤導性資訊的「安排」，目的並非限制任何一方對許可協議的商業自主權，而是為了影響監管機構和醫生等第三方選擇使用Avastin的行為。因此，散播不利於Avastin仿單標示外使用的資訊，此一共同協議，不能被認為是許可協議的附屬部分，係實施協議所必需的。其符合歐盟競爭規則的範圍，作為許可協議中的單獨協議。 雙方協議散布安全誤導性的不實資訊，針對此兩種相互競爭的醫藥產品，可能構成對競爭規則的嚴重違反：諾華與羅氏公司，在科學證據不確定的情形下，聯合對外向歐洲藥品管理局（European Medicines Agency, EMA）、醫療專業人員和公眾宣稱有關使用該仿單標示外藥物將造成不良副作用的誤導性資訊，以減少其對其他產品施加的競爭壓力，構成對「競爭對手」（by object）的限制。尤其令人憂慮的是，企業可能會透過散播資訊來減少藥品本身的競爭壓力，從而誇大使用其他產品將導致不良反應的可能性。
歐盟執委會關切奈米科技對於食品安全之影響近年來，奈米科技已多方使用於食品製造業中，舉凡食品的殺菌、保存或食材的包裝等，皆為適例。然而，隨著奈米科技的影響層面逐漸擴大，無論係其功用的研發或風險的防範，仍有進一步研究之必要。 歐盟執委會(European Commission)根據2007年3月其新興健康風險科學委員會(SCENIHR)所提出之報告，認為應加強認識奈米科技對於食品安全之影響，遂邀請歐洲食品安全局(EFSA)就該領域提出科學看法。至2008年10月14日，歐洲食品安全局科學委員會即公布「奈米科技對於食品和飼料所引起之潛在風險(Potential Risks Arising from Nanoscience and Nanotechnology on Food and Feed Safety)」草擬意見，其內容係說明奈米科技應用於食品製造業之多種樣態、人為奈米材料(engineered nano materials，ENM)於食品或飼料製造過程中所產生之作用，以及判斷現有之風險評估方式能否合於需要。 該草擬意見歸結數項結論如下： (1) 因人為奈米材料之體積微小且具有高表面積，於人體吸收時較一般物質更容易產生反應。 (2) 關於化學物質於奈米尺寸下將產生何種變化，迄今無法做出令人滿意之科學論斷，因此就安全性與相關數據的累積，仍需要個別檢視。 (3) 建議應針對風險評估一事設置國際基準，且該基準可同時適用於人為奈米材料及一般化學物質。 (4) 食品與飼料中含有人為奈米材料者，於風險評估時應包括該材料特性之敘述，並進行毒理研究分析，使資訊蒐集更為完備。 由於人為奈米材料不確定之事項甚多，因此需要更豐富的資料加以釐清；而該草擬意見除提供歐盟執委會評估現行法制、研究可行措施外，亦向公眾廣徵回應；民眾可於2008年12月1日前，提供歐洲食品安全局相關科學證據或意見，待該局進行彙整後，將與歐盟會員國商討後續事宜。
OTT服務所涉網路中立性與著作權議題之比較分析－美國與歐盟之新近法制及對我國之建議 世界衛生組織發布人工智慧於健康領域之監管考量因素文件，期能協助各國有效監管健康領域之人工智慧世界衛生組織（World Health Organization, WHO）於2023年10月19日發布「人工智慧於健康領域之監管考量因素」（Regulatory considerations on artificial intelligence for health）文件，旨在協助各國有效監管健康領域之人工智慧，發揮其潛力同時最大限度地降低風險。本文件以下列六個領域概述健康人工智慧之監管考量因素： （1）文件化與透明度（Documentation and transparency） 開發者應預先規範（pre-specifying）以及明確記錄人工智慧系統（以下簡稱AI系統）之預期醫療目的與開發過程，如AI系統所欲解決之問題，以及資料集之選擇與利用、參考標準、參數、指標、於各開發階段與原始計畫之偏離及更新等事項，並建議以基於風險之方法（Risk-based approach），根據重要性之比例決定文件化之程度、以及AI系統之開發與確效紀錄之保持。 （2）風險管理與AI系統開發生命週期方法（Risk management and AI systems development lifecycle approaches） 開發者應在AI系統生命之所有階段，考慮整體產品生命週期方法（total product lifecycle approach），包括上市前開發管理、上市後監督與變更管理。此外，須考慮採用風險管理方法（risk management approach）來解決與AI系統相關之風險，如網路安全威脅與漏洞（vulnerabilities）、擬合不足（underfitting）、演算法偏差等。 （3）預期用途、分析及臨床確效（Intended use, and analytical and clinical validation） 開發者應考慮提供AI系統預期用途之透明化紀錄，將用於建構AI系統之訓練資料集組成（training dataset composition）之詳細資訊（包括大小、設定與族群、輸入與輸出資料及人口組成等）提供給使用者。此外，可考慮透過一獨立資料集（independent dataset）之外部分析確效（external analytical validation），展示訓練與測試資料以外之效能，並考慮將風險作為臨床確效之分級要求。最後，於AI系統之上市後監督與市場監督階段，可考慮進行一段期間密集之部署後監督（post-deployment monitoring）。 （4）資料品質（Data quality） 開發者應確認可用資料（available data）之品質，是否已足以支援AI系統之開發，且開發者應對AI系統進行嚴格之預發布評估（pre-release evaluations），以確保其不會放大訓練資料、演算法或系統設計其他元素中之偏差與錯誤等問題，且利害關係人還應考慮減輕與健康照護資料有關之品質問題與風險，並繼續努力創建資料生態系統，以促進優質資料來源之共享。 （5）隱私與資料保護（Privacy and data protection） 開發者於AI系統之設計與部署過程中，應考慮隱私與資料保護問題，並留意不同法規之適用範圍及差異，且於開發過程之早期，開發者即應充分瞭解適用之資料保護法規與隱私法規，並應確保開發過程符合或超過相關法規要求。 （6）參與及協作（Engagement and collaboration） 開發者於制定人工智慧創新與部署路線圖之期間，需考慮開發可近用且具有充足資訊之平台，以於適合與適當情況下促進利害關係人間之參與及協作；為加速人工智慧領域實務作法之進化，透過參與及協作來簡化人工智慧監管之監督流程即有必要。