As a side note: Some of the license changes also block Debian from updating their intel-microcode package[1].
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14
E.g. "intel-microcode-legacy" and "intel-microcode" would be more diplomatic (disgustingly so IMO).
And one could argue that every package in non-free would deserve a "-legally-restricted" suffix.
The DFSG is a set of guidelines that define what can be considered true FLOSS.
The reason is to protect users from legal risks.
The argument from Intel is that the new changes don't actually affect distributions, as distributions are given the right to redistribute the microcode in the license (and this is separate to allowing third parties to publish benchmarks). Either that, or the lawyers at Red Hat and SUSE missed this somehow (though this is unlikely -- at SUSE all package updates go through a semi-automated legal review internally, similar to how openSUSE review works).
I do understand Debian's ethical issue with this though, and I applaud them for standing up for their users (though unfortunately it does leave their users vulnerable -- I imagine it was a difficult decision to make.)
[I work at SUSE, though I don't have any hands-on knowledge about how this update was being handled internally. I mostly work on container runtimes.]
[1]: https://www.theregister.co.uk/2018/08/21/intel_cpu_patch_lic...
As well as not redistributing it to mirrors, as they are unable to ask mirrors to accept a new license. [0]