3 ms·
This seems like it would be a big deal considering this whole thing is related to servers and I have to imagine some server operators are running Debian? Maybe
by ddtaylor 8y ago
This seems like it would be a big deal considering this whole thing is related to servers and I have to imagine some server operators are running Debian? Maybe at the bare metal level their all running RHEL, which I presume doesn't care about the license restrictions.
- cyphar 8y agoFrom the article linked in TFA[1], Debian appears to be the only distribution that is refusing to release it. Gentoo has made it so that you have to agree to the new license when upgrading your intel-ucode package, while other distribution vendors (Arch, Red Hat, and SUSE) all appear to be shipping it without issue. 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_licence/ https://www.theregister.co.uk/2018/08/21/intel_cpu_patch_lic...
- shakna 8y ago> Gentoo has made it so that you have to agree to the new license when upgrading your intel-ucode package As well as not redistributing it to mirrors, as they are unable to ask mirrors to accept a new license. [0] [0] https://bugs.gentoo.org/664134#c2 https://bugs.gentoo.org/664134#c2