[someonenice]

>> 3) Author is modifying the product behavior with their software. So yes author. You are still liable. Technically, your customers are first in the line of fire. But the likely sequence of steps is: Friendly Spectrum Representative will visit them first, have a chat, ask them to stop using the device, then leave them a lone and then come for YOU.

Few questions related to this. - Does this meant that recertification is required every time we load a different version of the software ? - How does this work for Computers and mobile phones ? The hardware is certified but you are loading different software daily.

[negative_zero]

In the purest theoretical sense yes, in practice no. So that you don't have to recert everytime, you

1) test and exercise your product to extremes so that you can say with high certainty that: no matter what the customer loads, it won't breach the rules.

2) As pjc50 mentioned: Lock down the parts which the user could potentially cause the most damage with. i.e lock down that radio firmware (why is why none of it is open source).

If you do (1) and (2) and a few other things, you buy down your risk sufficiently that you can confidently demonstrate that re-certs are not needed.

The Author of the parent article IMO is doing the exact opposite.

There are also half-way houses: Just doing "pre-compliance testing". So not a formal cert, your just doing a quick test in an anaechoic chamber or even on a table top scanner. Of course this only applies to things you can self-certify. Some things, like radios (WiFi, Bluetooth etc.), you cannot self-certify. That's why almost everyone buys the radio as a module (To buy down their risk). By consequence: That's why those radio module manufacturers have the firmware locked down hard and engineer and cert the radios to have big margins.

There are a lot of rules yes, but there is actually a lot of flexibility and common sense in the system too (but it is still imperfect, absolutely). But that flexibility does not allow for horsing around. If you can demonstrate to Friendly Spectrum Agency all this due diligence, you are going to have a MUCH better time.

[pjc50]

The "software" in these cases is localized to the drivers/firmware. This is why you basically can't get a RF peripheral for Linux with truly open firmware and they all use binary blobs: to prevent you modifying it.

[buescher]

It's complicated!

If it's not a transmitter, then it's not certified (this has a meaning), you just need to have acceptable data on hand for your Supplier's Declaration of Conformity (SDoC). Then if you make any changes to your product after test, it is a judgement call whether you need to retest. Ultimately you are responsible for compliance, so this is not a free pass. In principle your computer or cell phone manufacturer could get fined if it is possible to operate their device with new user software in a way that emits RF above allowable levels.

If it is a transmitter and you-the-manufacturer make changes to software that operates the transmitter, the FCC has specific rules. Look at the KDBs for permissive changes and for Software Defined Radio Applications. Note that the FCC has a somewhat unique idea of what constitutes an SDR. Some software changes to radio firmware will require recertification but some just will require a permissive change. Some permissive changes are handled in a way similar to SDoCs, where you just get yourself a report with acceptable data, some require filing that data with the FCC.