the summary is - and this surprised me to find out exactly what the FSF's
rules are - that basically average end-users must not be accidentally tricked
into running proprietary software (which could potentially end up spying on
them), for example like in Debian GNU/Linux you run synaptics, it presents
"nonfree" as one of the click-check-box options, there's absolutely no
warnings whatsoever about the dangers of installing non-free software, and
the average end-user really doesn't know what they're getting into with that.
*this* is the scenario that the FSF's rules are intended to cover - *NOT*
the average TECHNICAL end-user usage-case where they're competent enough to
know how to compile up code (even though they can't program), follow
instructions online and generally make informed decisions about what they're
getting into.
so in talking to the FSF i was surprised to learn that if we simply don't
compile in mali.ko into the linux kernel, then because it's LITERALLY
IMPOSSIBLE to gain access from userspace to that proprietary piece of
graphics - as in, there's nothing that the user can do which would allow them
to even know that MALI was even on the SoC - turns out that that's good
enough to be able to apply for an "Exemption" under the FSF's RYF
Certification Programme.
now, exemptions *specifically* require a Board Meeting to evaluate them, and
that means in effect that Dr Stallman needs to evaluate it, but chances are
high that we'll be ok.
what that *doesn't* mean is that it's okay for ARM to get away with messing
everyone about. this should *NOT* be used as an excuse by ARM to continue to
do what they're doing. and i can tell you right now that if we had any other
choices - any truly libre SoCs with full 3D graphics - i would certainly be
using them. this processor therefore represents the nearest stepping-stone
to get to where we want to be.
