It's an interesting edge case when you have someone actually <i>moving</i> from one model to another. But I think even OpenBSD's famously strong policy on binary blobs would allow this one, at least as they've implemented the policy in the past. They require source for <i>drivers</i>, which means anything you need to load onto the chip or use to communicate with it, but not for every piece of ROM that's internal to a chip. For example, Intel and AMD both microcode some instructions in firmware on their chips, rather than implementing them in silicon, and OpenBSD is ok with that, treating the silicon and microcoded part as all part of the blackbox chip package, rather than as a "driver" that requires source.
To be fair, I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. So even if we had full source code to the radio's firmware, it would be illegal to sell a device that could be user-programmed. Or something.<p>(I don't know how widely enforced this is, though. I've never had any trouble telling my wifi equipment I'm outside of the US to get access to extra channels. I guess this is a federal crime, but good luck enforcing it.)
Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding the blob from the user makes it okay, why not apply that thinking to drivers wrapped by the NDISwrapper?
I wonder how hard it is to swap peripheral chips in embedded solutions like this? And more importantly, are there any WLAN chips with good blobless drivers? Somehow it seems that they always have been a pita for Linux
What if, instead of moving the software to a binary blob, they went a bit nuts and moved it to an ASIC that did the same job in random logic? That is, what if they re-implemented the software in pure hardware?