Do you have a link for that? I'd like to see it...
It's the very same document - I'd encourage everyone to read it in full. There are only 3 pages of content after all: "Software Security Requirements for U-NII Devices" [1]. But keep in mind - this is not representative of the actual license conditions and regulations, it is a piece of bureaucratic administrivia that helps the FCC staff process and assess your applications!
"2. What prevents third parties from loading non US versions of the software/firmware on the device? Describe in detail how the device is protected from "flashing" and the installation of third party firmware such as DD-WRT."
Again, I think people are picking stuff at random and missing the context. I could find much scarier wording than this if you really wanted to FUD this up some more. This is part of a bureaucratic administrative process used to help assess applications.
It even says that follow-up questions may be asked. As someone familiar with regulatory compliance processes in another country (.au), just because you answer in the negative does not mean your application will be rejected - your other responses (see the rest of the questions to see how redundant they are) will be taken into consideration.
Even though we have the old joke where our equivalent of the FCC has an unofficial motto, "We're not happy until you're not happy", even bureaucrats have enough imagination to see that scripted questions can't capture every single possible way to meet the underlying requirements for a given regulatory compliance issue.
The questions are centered around identifying how the device is restricted from operating outside of the conditions asserted and tested in the conformance documentation submitted with the FCC registrant's application. That's not an unreasonable expection from a spectrum regulator's POV, but it is terrifying given that this will likely mean region-locked (or region-specific) devices - choosing a country from a drop-down list will become a thing of the past (after all, 5GHz is carved up quite differently in different parts of the world compared to 2.4GHz, where things are already a complete mess).
Whilst you might find that "OMG, these questions seem to assume that the FCC wants only OEM-approved firmwarez", as per the DD-WRT wording this is because the questionnaire has been written from the assumption that these drastic measures are necessary to meet the new regulations. If you read the proposed regs themselves, carefully [2], I don't see anywhere where the "host device" is explicitly required to control OS firmware unless this is the only means that the registrant can meet the U-NII security requirements.
It doesn't help that we have a whole new population of people trying to read and understand these documents (me included). They use the term "software" rather loosely, and you have to have some background understanding of how the existing FCC registration/approval/certification process works (difference between an approval for a host device vs module etc).
I even see people mixing up the SDR rules. Technically an SDR product must undergo a completely new FCC approval process with new validation test results/proof of conformance for every firmware update! There's no way WiFi router AP vendors are going to go down that path; this is reserved for things like mobile phone baseband firmware that change infrequently and are profitable enough (check out Qualcomm's profits) to actually afford to be able to do this.
This [2] basically summarizes the intent behind the U-NII security requirements:
Manufacturers must implement security features in any digitally modulated
devices capable of operating in any of the U-NII bands, so that third parties
are not able to reprogram the device to operate outside the parameters for which
the device was certified. The software must prevent the user from operating the
transmitter with operating frequencies, output power, modulation types or other
radio frequency parameters outside those that were approved for the device.
Manufacturers may use means including, but not limited to the use of a private
network that allows only authenticated users to download software, electronic
signatures in software or coding in hardware that is decoded by software to
verify that new software can be legally loaded into a device to meet these
requirements and must describe the methods in their application for equipment
authorization.
[1]
https://apps.fcc.gov/kdb/GetAttachment.html?id=1UiSJRK869Rsy...[2] http://www.ecfr.gov/cgi-bin/retrieveECFR?gp=1&SID=9a15d7771e...
Edit: I guess you meant the Ars article! Here it is:
http://arstechnica.com/information-technology/2015/09/fcc-ac...
Ars is attempting to schedule an interview with the FCC to explore this issue in
more depth. So far, the commission has only told us that “versions of this open
source software can be used as long as they do not add the functionality to
modify the underlying operating characteristics of the RF [radio frequency]
parameters. It depends on the manufacturer to provide us the information at the
time of application on how such controls are implemented. We are looking for
manufacturers of routers to take more responsibility to ensure that the devices
cannot be easily modified.”