Yes, you are right to some extend and this argument is exactly what is currently debated with the FSF and others. The basic idea is to treat a device which contains the firmware in some form of internal storage as hardware - like some other chip which has a specified function, you get a documentation for it and you can be ind f sure that this hardware will always work the same way and can not be tweaked to do malicious things without you noticing.
But this clearly opens up the question of how to handle security updates. These “pieces of hardware” have become so ‘smart’ and complex that they are likely to have bugs and will need updates at some point - updates you really want to have to protect you. The FSF is aware of this issue and we (and others) are in discussion with them how to best cope with this - maybe by some form of change or exception for the RYF rules, we don’t know yet.
But up to now it is like it is, i.e. firmware is to be stored on the piece of hardware and the OS shall not touch it - unless the firmware is fully open and free. Reverse engineering the two files for the BT of the AR3k would be pretty awesome! This would allow the firmware download and be RYF compliant.The RAMPS file of the AR3k is, I am pretty sure about this, only a binary parameter file. The real code is in the second file that gets loaded (and which can be ignored for now). The RAMPS file has a couple of prettty regular structures which shouldn’t be too hard to rev-eng. That would be very awesome!
Cheers
nicole