開放原始碼協會(Open Source Initiative,簡稱OSI)的新任總裁Russ Nelson在
在寄給開放原始碼社群的一份聲明裡,Nelson表示,新的條款規定:授權不可與既有的授權重覆;必需以清楚、簡單,而容易了解的方式撰寫;以及把個人、專案或組織的名稱通通移至隨附的附件中,以便讓授權書可重複使用。
Nelson在接受專訪時表示,新條款要由OSI董事會通過才可生效。董事會成員已經過過該提案,但還未安排好投票的議程。OSI並不打算取消已經通過的授權認證,Nelson表示。他認為,推出「OSI Gold」升級認證應該可達到同樣的效果。他進一步表示,新的條款是否能夠有效減少授權數量,還要看執行是否有力。
本文為「經濟部產業技術司科技專案成果」
2025年9月15日,韓國智慧財產局(Korean Intellectual Property Office,下稱KIPO)與韓國外交部轄下之海外僑胞廳 (Overseas Koreans Agency,下稱OKA)共同宣布:即日起,「營業秘密原本證明(Trade Secret Original Certificate)」無須經過公證人的公證程序,即可直接申請海牙認證(Apostille)。此項政策旨在簡化韓國企業在海外保護其營業秘密的程序,減輕企業的時間與金錢成本。 在KIPO與OKA尚未推出該新政策前,依據韓國《不正競爭防止法》第 9-2條第3款規定,推定註冊此營業秘密原本證明者在註冊的時點,已擁有該電子文件所記載的資訊。然而,海牙認證僅頒發給「官方文件」,非官方機構所核發的營業秘密原本證明在國際上不會被視為官方文件,即營業秘密原本證明僅在韓國國內生效。當韓國企業積極擴展海外市場或在海外面臨營業秘密侵權糾紛時,企業如欲將營業秘密原本證明申請海牙認證以作為跨國訴訟之證據,需經過以下3步驟: (1)將其含有營業秘密內容的電子文件,向KIPO指定的原本證明機構申請註冊「營業秘密原本證明」。 目前KIPO指定4家非官方\機構,如韓國智慧財產權保護院(한국지식재산보호원)、LG CNS、RedWitt、Onnuri 國際營業秘密保護中心。以韓國智慧財產權保護院之流程為例,該機構自電子文件生成獨一無二的數位指紋(Hash,或稱雜湊值),與時間戳技術結合,製作營業秘密原本證明,以確保在特定時間點,該文件確實存在,且之後未被變更。即使對文件的微小修改都會影響數位指紋,使營業秘密原本證明失效。 (2)將其營業秘密原本證明交由公證人公證。 (3)取得公證人公證後,方得依據《關於官方文件簽發海牙認證及領事認證規定》(總統令)(공문서에 대한 아포스티유 및 본부영사확인서 발급에 관한 규정」(대통령령))向主管機關(即OKA)申請海牙認證。 9月新政策將「營業秘密原本證明」納入「可直接申請海牙認證的文件範圍」,即企業在取得由 KIPO 指定機構所核發的原本證明後,不須經公證流程,可直接申請海牙認證。此舉簡化行政程序,且經海牙認證為韓國真實文件之營業秘密原本證明,在海外爭議中可作為官方文件,提升公信力。 綜上可得知,韓國營業秘密原本證明的服務僅留存電子文件的最終版本所生成之數位指紋,而非註冊當時的電子文件本身。因此,本文建議企業仍應先打好文件管理機制的地基,簡要說明如下: 1.第一步,選定有價值、有高度洩密風險或即將對外共享的數位資料(如研發紀錄、客戶名單、演算法等),明確該資料相關之權責人員與作業規範。 2.第二步,建立可行之重要數位資料的生命週期(自原始資料之生成、保護到維護,再延伸至存證資訊之取得、維護與驗證)流程化管理機制,確認具備與管理流程相應的資源(如人員面之保密契約、教育訓練以及環境面之系統備份等)。 3.第三步,檢視現行規範與實際執行之情況與分析落差原因。 4.第四步,因應管理機制落實之程度、內外部變動之需求,進而調整合適的管理作法。 前述建議之管理作法已為資策會科法所創意智財中心發布之《重要數位資料治理暨管理制度規範(EDGS)》所涵蓋,企業如欲強化數位資料管理機制,可以參考此規範。 本文為資策會科法所創智中心完成之著作,非經同意或授權,不得為轉載、公開播送、公開傳輸、改作或重製等利用行為。 本文同步刊登於TIPS網站(https://www.tips.org.tw)
歐盟監察官日前指出,ISP業者的流量管理可能違反資料保護及隱私法歐盟資料隱私保護監督官(European Data Protection Supervisor, EDPS)Peter Hustinx呼籲歐盟,儘速建立專家小組,制定指導原則,將資料保護以及隱私原則納入網路中立原則中(Network Neutrality)。 網路中立原則原係要求對於網路服務提供者之間不應有所歧視,應平等對待所有資料。但是,在符合歐盟法規下,ISP業者亦得針對網路內容提供者或終端使用者,以不同收費方式管制網路流量。判斷的準據,則以使用者在網路上傳遞的個人訊息為主。調查官Hustinx在其意見書中指出,調查使用者傳遞的訊息可能會背離歐盟資料與隱私保護相關法律。 根據歐盟的隱私及電子通訊指令(Privacy and Electronic Communication Directive),ISP業者在某些條件下,得以促進通訊傳輸為目的,處理個人資料,但是必須取得使用人同意。這項指令亦要求ISP業者必須採取適當的技術、組織措施以確保資料的安全。承此,Hustinx就網路中立性所提出的意見,即為前述指令之例外,亦即ISP業者在確保網路順暢及監督是否有干擾時,其監控行為無須使用者同意。但若為限制某些服務,例如檔案交換,而進行的監控行為,則不在此限。再者,該同意必須免費的、明確的並且使用者得了解的。Hustinx提出的指導原則強調確保網路使用者被適當的告知,進而了解該項個人資料監控的意義而做出同意與否的決定。同時,ISP業者在進行調查時,亦應謹慎為之,不違反比例性原則。
歐盟支付服務指令(PSD)將進行翻修,然而進程延宕歐盟執委會於2013年7月24日提出支付服務指令(Payment Service Directive,簡稱PSD,Directive 2007/64/EC)修正案,簡稱PSD2。最新消息指出,PSD2將無法在本屆歐洲議會審議完成,需於五月歐洲議會改選後,在新一屆的議會中再行審議。 PSD公布施行於2007年,該法降低支付服務市場新参進者(也就是非銀行業者)進入市場的困難度,活絡支付市場的競爭,提供消費者更多的選擇,並強化消費者保護。PSD讓「支付」在歐盟內更快更方便。 本次歐盟提出修正案,其修正目標包含: 一、提高歐盟支付市場的整合以及效率。 二、提升支付服務提供者(包含新参進者)的營運範圍。 三、確保強化消費者保護以及資訊安全。 四、鼓勵支付服務的減價。 五、促進共通技術規範以及互用性(interoperability)的形成。 實際做法,PSD2大致有以下修正重點: 一、因應科技發展及時代變遷,擴大適用範圍: (一)提出「第三方支付服務提供人(third party payment provider,簡稱TPP)」之名詞定義,並量身打造規範。原本PSD的附件(Annex)中關於「支付服務」定義,第七款「透過電信、數位或IT設備接收支付服務使用者的指示執行支付交易,而支付的進行也是透過電信或IT系統或網路營運人,而且只是擔任服務使用者與商品或服務提供人的中間媒介。」已可包含目前我國俗稱的第三方支付服務。本次PSD2則在第14條第11項中提出「第三方支付服務提供者」此名詞,對照於附件一(Annex I)第七款中,係指: 基於存取其他支付服務提供人之支付帳戶而提供下述服務- 1.發動支付服務; 2.帳戶資訊服務。」 例如透過TPP與銀行帳戶界接,從銀行帳戶扣款進行支付;或者是與信用卡界接,進行扣款。 依照PSD2,TPP為支付服務提供者(Payment service providers, 簡稱PSPs),因此也需要取得各國主管機關之許可方能進行營業。 (二)透過手機或者是其它IT裝置進行的行動支付,如果單筆支付金額超過50歐元,或者是月支付金額超過200歐元,也應適用PSD2。 二、強化資安要求: (一)歐盟將另提出「網路及資訊安全指令(Direvctive on Network and Information Security,簡稱NIS Directive)」,PSPs應遵循之。 (二)歐洲銀行管理局(European Banking Authority,簡稱EBA)將與歐洲央行(ECB)密切合作,提出資訊安全指導原則(guidelines),以輔導PSPs建立並執行、監控資安以確保PSPs符合資安事件處理要求。 三、強化消費者保護: (一)PSD對於支付服務應揭露資訊的規定只適用於支付全部在歐盟境內發生者,PSD2則要求對於涉及第三國以及外幣之交易,只要有任一支付服務提供者是在歐盟境內,都要適用。 (二)只要支付未經授權,應立即退款給付款方。 (三)保障無條件退款權,但是如果商品或服務已經完成消費則不在此限,例如下載的影片已經被觀賞完畢。 (四)無需另外授權的交易(如免輸入帳密之交易),額度從原本的150歐元下調為50歐元。 對於客訴爭議,PSPs應於15個工作日內以書面回覆。
世界衛生組織發布人工智慧於健康領域之監管考量因素文件,期能協助各國有效監管健康領域之人工智慧世界衛生組織(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) 開發者於制定人工智慧創新與部署路線圖之期間,需考慮開發可近用且具有充足資訊之平台,以於適合與適當情況下促進利害關係人間之參與及協作;為加速人工智慧領域實務作法之進化,透過參與及協作來簡化人工智慧監管之監督流程即有必要。