自由軟體運動燒向BIOS
BIOS是「基本輸出/輸入系統」（Basic input/output systems）的簡稱，這種在所有應用底層的軟體，過去以來PC廠商一向自我保護相當嚴密，而且還需要用到專門設計BIOS的公司。而現在，一些批評開始希望逼迫業界放棄其機密，這些批評宣稱，客戶應該可以自由發開自己的選擇方案，確保可以控制自己的裝置──也就是說，可以讓他們自由取得BIOS資訊。
「我們需要自由的BIOS，因為如果我們無法控制BIOS，就無法控制電腦。」自由軟體基金會（Free Software Foundation）總裁Richard Stallman表示。BIOS自由軟體計畫開始於BIOS史上的第一波改革──當時軟體程式碼希望轉向新的「可延伸式韌體界面」（Extensible Firmware Interface，或簡稱EFI）。另一方面，PC硬體安全功能的一些計畫也讓Stallman等一類團體批評指出，消費者對於自己的裝置缺乏主控權，希望能夠公開BIOS撰寫規格，可讓消費者能夠自行安裝、修改，及再發佈BIOS軟體──雖然不見得會是免費的。更重要的是，將可讓使用者避開未來一些可能的安全強化功能，例如廠商用控制文件使用方式的數位版權管理功能。
已有許多廠商宣稱，BIOS的自由軟體純粹只是為了自由而自由，對於電腦使用者沒什麼意義。BIOS廠商的高層及晶片巨子英特爾都表示，由於目前業界對BIOS的控管嚴密，也才能夠保有PC的安全和穩定，同時可藉由對一些廠商IP（智慧財產權）的保護以促進市場競爭。有些人則認為，對於BIOS的嚴密保護，有助於防止駭客攻擊。
英特爾則已經提出了折衷的方案──名為Tiano的開放原始碼技術。Tiano是為了取代BIOS的一種框架工作，希望透過EFI，讓PC零件以自己的驅動程式來啟動零件。英特爾的這項計畫為BIOS的汰換工作建立了一個框架，因此可能成為BIOS自由軟體的基礎。但是它把PC零件初始化用的程式碼撰寫工作留給了軟體的下載者。但Stallman依然宣稱英特爾做得不夠，且BIOS廠商其實是多餘的，他希望看到資訊釋出。
本文為「經濟部產業技術司科技專案成果」
陳怡玫
副主任兼規章法制組組長 編譯整理
近期軟體產品(特別是演算法)的智慧財產權保護受到各界廣泛注意，2022年12月美國實務界律師特別撰文對此提出相關智財權保護建議。軟體產品通常涉及演算法，指由人工智慧(AI)和分析組成，用於解決特定問題的一組規則。專利通常被企業預設為保護技術產品的最佳形式。 然而在2014年，美國最高法院在Alice Corp. v. CLS Bank International一案中可以發現將軟體申請專利保護可能存在風險，如：（一）軟體可能被認為是抽象概念(abstract ideas)，非專利適格標的，而無法受專利法保護；（二）通常不易主張專利權，或可能在訴訟過程中因舉證責任造成機密資訊揭露等風險。因此該文作者認為難以受專利法保護之演算法、用於基於機器學習或訓練模型的資訊和資料集等軟體資料，亦可考慮透過營業秘密來保護，並提出以下營業秘密管理的建議： 1.員工教育訓練：建議企業可在僱傭的各階段(僱傭時、每年、終止時)採行相關措施、訓練，以減少營業秘密的竊用，及防止未來員工抗辯不知道該資訊是營業秘密。 2.機密標示：建議企業透過此階段審視組織對於機密文件之界定，再透過機密標示配合存取權限設定，協助企業控管與防止機密外流。 3.執行：瞭解需要受管理的營業秘密是什麼以及其為何重要。 4.監控和衡量員工參與度：建議企業採取相關監測機制檢視員工活動，及早發現離職動向與管控營業秘密資訊。 5.避免資訊揭露：建議企業應確保在向消費者或客戶行銷的過程中不洩露營業秘密，或至少採取相關保護措施，如簽訂保密契約。 6.確保資料安全：建議企業可建置網路安全策略、設置密碼、存取限制、外部設備使用下載或儲存限制等管控措施。 綜上所述，對於從事軟體開發的企業，除以專利保護產出成果外，還可從技術本質、後續是否容易主張、是否適合公開等面向，評估搭配營業秘密保護成果。並在選擇以營業秘密保護成果時，採行相關的管理措施避免營業秘密外洩而造成企業損失，包括：劃定需管理的營業秘密、制定員工教育訓練與相關管制措施，如機密標示、權限控管，並可搭配預警機制以便能夠即早發現異常。 本文同步刊登於TIPS網站（https://www.tips.org.tw）
法國CNIL發布針對應用程式的隱私保護建議在民眾越來越依賴行動裝置的應用程式進行日常活動的年代，諸如通訊、導航、購物、娛樂、健康監測等，往往要求訪問更廣泛的資料和權限，使得應用程式相較於網頁，在資料安全與隱私風險上影響較高。對此，法國國家資訊自由委員會（Commission Nationale de l'Informatique et des Libertés, CNIL）於2024年9月發布針對應用程式隱私保護建議的最終版本，目的為協助專業人士設計符合隱私友好（privacy-friendly）的應用程式。該建議的對象包含行動裝置應用程式發行者（Mobile application publishers）、應用程式開發者（Mobile application developers）、SDK供應商（Software development kit, SDK）、作業系統供應商（Operating system providers）和應用程式商店供應商（Application store providers），亦即所有行動裝置生態系中的利害關係者。以下列出建議中的幾項重要內容： 1. 劃分利害關係者於手機生態系中的角色與責任 該建議明確地將利害關係者間作出責任劃分，並提供如何管理利害關係者間合作的實用建議。 2. 改善資料使用許可權的資訊提供 該建議指出，應確保使用者瞭解應用程式所請求的許可權是運行所必需的，並且對資料使用許可的資訊，應以清晰及易於獲取的方式於適當的時機提供。 3. 確保使用者並非受強迫同意 該建議指出，使用者得拒絕並撤回同意，且拒絕或撤回同意應像給予同意一樣簡單。並再度強調應用程式僅能在取得使用者知情同意後，才能處理非必要資料，例如作為廣告目的利用。 此建議公布後，CNIL將持續透過線上研討會提供業者支援，協助其理解和落實這些建議。同時，CNIL表示預計於2025年春季起，將對市面上應用程式實行特別調查，透過行政執法確保業者遵守相關隱私規範，尤其未來在處理後續任何投訴或展開調查時，會將此建議納入考慮，且會在必要時採取糾正措施，以有效保護應用程式使用者的隱私。 .Pindent{text-indent: 2em;} .Noindent{margin-left: 2em;} .NoPindent{text-indent: 2em; margin-left: 2em;} .No2indent{margin-left: 3em;} .No2Pindent{text-indent: 2em; margin-left: 3em} .No3indent{margin-left: 4em;} .No3Pindent{text-indent: 2em; margin-left: 4em} .Psrc{text-align: center;}
英國發布《資料主體近用權指引》說明資料近用權法遵重點及實例解析英國資訊委員辦公室（Information Commissioner’s Office, ICO）於2020年10月21日發布《資料主體近用權指引》（Guidance of Right of access），針對資料主體行使資料近用權之請求（Data Subject Access Request, DSAR），受請求之機構應如何進行識別判斷、簡化處理方式，以及特殊例外情況等法遵重點提供指導方針，並進行實例說明解析，以幫助受請求之機構在面臨資料主體之近用權請求時能快速且有效的處理。 英國「個人資料保護法」（The Data Protection Act 2018）依據歐盟「一般資料保護規則」（GDPR）於2018年重新修訂，其中資料近用權更是對於資料主體相當重要的基本權利，進而影響受請求之機構必須了解如何有效率的處理資料近用權之請求，並確實履行其在法規上所要求的保護義務，主要分為三點： 在資料主體確認其資料近用權所欲請求的範圍之前，受請求之機構依法應回覆時限應予以暫停，以利受請求之機構能有更充裕完整的時間釐清及回應資料主體之近用權請求。 為了避免受請求之機構耗費大量時間判斷何謂「明顯過度之請求」（manifestly excessive request），該指引提供相關定義說明及判別標準。 針對「明顯過度之請求」收取處理費用所包含的項目，例如受請求之機構處理請求所增加人力行政成本，在受請求之機構收取處理費用時可將其納入斟酌。
美國國家公路交通安全管理局發布自駕車安全性評估相關法規預告美國國家公路交通安全管理局（National Highway Traffic Safety Administration, NHTSA）於2025年1月15日發布「配備自動駕駛系統車輛之安全、透明度及評估計畫」（The ADS-equipped Vehicle Safety, Transparency, and Evaluation Program , AV STEP）法規預告（Notice of proposed rulemaking, NPRM），建立全國性自願評估與監督制度，以提高自駕車安全性之公共透明度，並促進其負責任布建。 根據《國家交通與機動車輛安全法》（National Traffic and Motor Vehicle Safety Act），自駕車在符合〈聯邦機動車輛安全標準〉（Federal Motor Vehicle Safety Standards, FMVSS）及州、地方法律的前提下，得於公共道路上行駛；若無法符合FMVSS之要求，則需進行豁免申請。惟不論採何種途徑，FMVSS皆未針對自駕車之安全性與性能進行評估，因此NHTSA提出AV STEP，為自駕車設計專門之豁免申請途徑，並針對不同自動化程度車輛提出涵蓋車輛設計、開發與運行之安全性審查條件，以對現行FMVSS之豁免規定進行補充。簡要說明如下： （1）需配置駕駛人之自駕車：需具備手動駕駛功能與清晰的交接程序，以於自駕系統失效時透過充分提示與反應時間，使駕駛人接管操作。 （2）完全由自駕系統操作之自駕車：監管著重於各種情況下皆能自主運作、回退（Fallback）機制需具遠端監控能力，且能自動進入最小風險狀態。 除上述要求外，申請者皆須提供第三方機構之獨立評估報告、說明自動駕駛系統故障之應對措施，並持續接受NHTSA監督。