The only reason for the Bronze classification is the GPU firmware / driver. I'll admit I'm not as familiar with the RK3822 GPU as I'd like, so if I made an error and it operates without binary blobs then the C201 would be reclassified Platinum. You can't exactly stick a third-party GPU on that SoC to get around the built-in GPU, so if it's not free it's a major problem.
Fair enough. I didn't count the GPU driver because your defintions only say "firmware", and I wouldn't call it that (it's a normal kernel driver, just not open source). If we're getting into normal driver support things start getting more complicated (e.g. would you count an Nvidia graphics card as "free"? There is Nouveau, but it's generally not considered as fast/stable/complete as Nvidia's proprietary drivers).
I think it's fair to penalize boards for this, but not as hard as for other components. The machine is still perfectly useable with text mode or software rendering. I would say this is way less severe than a non-free EC (which essentially means you can't trust your keyboard), for example. It should rank somewhere among the low inconveniences, maybe similar to a non-free WiFi chip.
I am trying to head off the easiest thing possible for the manufacturer
- -- that is, produce a board that has one feature set for Windows, and
another very limited feature set for libre software. I don't think the rankings should be able to be gamed in that manner; when a consumer buys a board they expect that the advertised features of that board work, and without proprietary software so if we've listed it as Gold or Platinum.
I highly doubt that anyone would bother shipping a whole extra SKU solely to look good to libre enthusiasts, to be honest. The cost for that is not trivial.
Anyway, I guess it's fair to rate what's on the board. But the ratings should take into account the importance of the component, like I tried to outline with the list below (e.g. how necessary is it to make the machine usable, and what options does the user have to avoid the proprietary parts).
Why are you assuming the internal ROM microcode is safe? I certainly wouldn't go there; in fact, the errata sheets for most processors show the exact opposite.
I'm not... but getting into that opens another theoretical can of worms that I don't think you can really fairly assess. As long as you don't have the full hardware sources for the CPU, there is no externally visible difference between a "perfectly free" CPU and one that contains ROM microcode... you can never know if the vendor didn't put a backdoor right in the hardware (or if a chip that you think is decoding instructions directly is actually using non-updateable microcode). So I think if you want to take microcode into account, the choice to reject later updates is really the only one the user has.
I make a very limited exception for an EC that is only an EC; that is, it has no ability to transmit any information it gleans to a third party. I'd like to see that exception disappear ASAP, but I think we should wait until the free EC implementation for the Lenovo machines is finished so that we at least have some examples of true Silver class machines.
Maybe. But it means that any temporary exploit at a later time (including running a firmware update tool for your proprietary EC or something like that) could expose anything you ever typed. It also means that you can't convert your machine from a trusted to and untrusted OS anymore by just wiping everything... you never know what the EC has still tucked away somewhere (assuming it has flash, which I think most do). Why not focus on the boards with free ECs we have already?
A. Everything free. B. Non-essential component (e.g. GPS sensor) requiring proprietary firmware. C. Network component (e.g. WiFi) requiring proprietary firmware if it can be bypassed (e.g. USB, expansion card). D. Input/output-sniffing component (pointing device, keyboard, display, audio) requiring proprietary firmware if it can be bypassed, or CPU requiring microcode if it can be bypassed (e.g. just using factory ROM code). E. CPU or equivalently privileged processor requiring non-resident proprietary boot firmware. F. Network component requiring proprietary firmware that cannot be bypassed (e.g. no USB ports). G. Input/output-sniffing component requiring proprietary firmware that cannot be bypassed, or CPU requiring microcode that cannot be bypassed. H. CPU or equivalently privileged processor requiring resident proprietary firmware (e.g. Intel ME, Qualcomm TrustZone).
My concern is mainly the number of levels. If we make this too much of a smooth gradient type thing people won't really understand just how bad G and H really are.
Okay, sure... colors or naming could make that more clear, or just squash some of these categories together. I didn't really want to exemplify the granularity here, just how I think different non-free components should be weighted against each other to fairly represent the risk to the user.
We could also try a system of points that get added together to reach a certain category (e.g. proprietary microcode is worth 5 malus points, proprietary WiFi could be 2, and resident proprietary firmware with full access short-circuits to the lowest category).