Firmware Exclusions and the Legacy Carve-Out: What Changed from the Draft Rule?

But it's the question is considering firmware is essential to safety, why is this excluded? I think the short answer is we don't really know. The the, in the draft version of the rule, the firmware exclusion was actually quite broad, and we were pretty surprised when we were looking at it, speaking for finite state. And then when the final rule came out, it got defined a much, much more narrowly. And so I I think the the the while there's still some mystery as to the reason for excluding firmware, what I will say is it doesn't have a dramatic impact on the scope of the rule because it's been defined much more narrowly than it was in the in the draft rule. Matt, do you wanna comment on that quickly before we proceed? Eric is is spot on here. When when the draft came out, the rule the the firmware definition, which is an exclusion, it it explicitly carves out firmware, as as not being covered. That definition at at the outset of the draft was broad enough that you could cover things like even potentially, drivers that are inside of a Linux kernel, even possibly an entire Linux operating system if it was just designed for that particular hardware. It was a pretty broad definition. The definition the text itself has not changed from the from the draft. They define firmware as, software that is specifically programmed for a hardware device with a primary purpose of directly controlling, configuring, and communicating with that hardware device. But what they did was they added definitions examples around it that said to explain what is not firmware. And they did include things like system software, operating systems, for example. They included things like drivers that are that are not specifically firmware. So, really, where, you know, our view of this is right now is that we're talking about primarily, like, the bootloaders and very, very tiny embedded firmware, that might be resident in that in that device itself that has excluded everything else that is really doing any functionality, with with respects to, like, communications, protocols, higher level operating systems, applications that are facilitating communications, those are all in scope. Thank you. So I do wanna turn quickly to the the legacy software exclusion. In particular, it also represents or reflects a change from the draft rule to the final rule. The draft rule did not include this exclusion, but I think, in a nod to the short timelines and the potential disruption to supply chains, commerce added a an exclusion for legacy software. And let me just turn quickly to Christian to explain what that is and and how it works. Sure. And and so this only applies to software. It does not apply to hardware. But I think really, you know, the challenge is basically how do you trying to, divine the origins of software is particularly challenging for all the reasons that Matt, started off with. And because of that and, because of the short timeline, this legacy, software carve out was included, which basically says that you could have covered software that is linked to China. And so long as prior to March seventeenth of, of twenty twenty six, that software is no longer maintained, augmented, or otherwise altered by a China or Russia related entity, then it fits within, this carve out, and it could be could then be, used by in the US supply chain and not, trigger one of the prohibitions and not fall within the definition of covered software. That's creating you know, there's a lot of interest in that and a lot of, you know, questions about what needs to be done ahead of time, you know, to either, you know, restructure supply chain, you know, within an organization, say that all the software was in the organization. You can figure out how to, you know, you know, set up your supply chain to and your your your software, maintenance and and work on that, within a company. But, also, if you're dealing with a third party, for instance, like a China or rush Russia related entity, is there a way to, you know, transfer that software over ahead of time? And what is permissible in terms of a contractual relationship with that party to transfer that over? Is it a royalty structure, and what kind of royalty structure would be, permissible? Because there's some other guidance in the the regulations that call into question, you know, ongoing royalty, arrangements, which isn't how the rule reads. So there, again, a lot of ambiguity on that point, and I think a lot of people are are thinking about this right now about, you know, what transfers need to occur and and how do we, prepare for the legacy carve out.