6 ms·

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

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 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906158#14

deleted 8y ago
[deleted]
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 ago
  From 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
mpartel 8y ago
My guess is Intel will revert the license change soon. It's just too absurd to stay. But if not, I wonder if distros could have two packages, named with appropriate and well-deserved passive-aggressiveness, e.g.: intel-microcode-insecure and intel-microcode-legally-restricted.
- jgtrosh 8y ago
  And maybe they'll mark benchmarking packages as conflicting with intel-microcode-legally-restricted?
  - akx 8y ago
    Installing the benchmarking package, or running it, isn't against the license. Providing or publishing (comparative?) numbers while the microcode package is applied would be.
- dvfjsdhgfv 8y ago
  There is nothing passive-aggressive in intel-microcode-legally-restricted, it's just a statement of fact.
  - mpartel 8y ago
    It's not quite that clear cut IMO. 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.
- deleted 8y ago
  [deleted]
JdeBP 8y ago
As discussed at https://news.ycombinator.com/item?id=17801474 https://news.ycombinator.com/item?id=17801474 .
debiandev 8y ago
Debian has a dedicated archive, named "non-free", for everything that does not comply with the DFSG. The DFSG is a set of guidelines that define what can be considered true FLOSS. The reason is to protect users from legal risks. https://www.debian.org/social_contract#guidelines https://www.debian.org/social_contract#guidelines https://www.debian.org/doc/debian-policy/ch-archive.html https://www.debian.org/doc/debian-policy/ch-archive.html
dhimes 8y ago
Would be cool if this was blown out by the courts.

deleted 8y ago

[deleted]

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 ago
From 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

mpartel 8y ago

My guess is Intel will revert the license change soon. It's just too absurd to stay. But if not, I wonder if distros could have two packages, named with appropriate and well-deserved passive-aggressiveness, e.g.: intel-microcode-insecure and intel-microcode-legally-restricted.

jgtrosh 8y ago
And maybe they'll mark benchmarking packages as conflicting with intel-microcode-legally-restricted?
- akx 8y ago
  Installing the benchmarking package, or running it, isn't against the license. Providing or publishing (comparative?) numbers while the microcode package is applied would be.
dvfjsdhgfv 8y ago
There is nothing passive-aggressive in intel-microcode-legally-restricted, it's just a statement of fact.
- mpartel 8y ago
  It's not quite that clear cut IMO. 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.
deleted 8y ago
[deleted]

JdeBP 8y ago

As discussed at https://news.ycombinator.com/item?id=17801474 https://news.ycombinator.com/item?id=17801474 .

debiandev 8y ago

Debian has a dedicated archive, named "non-free", for everything that does not comply with the DFSG. The DFSG is a set of guidelines that define what can be considered true FLOSS. The reason is to protect users from legal risks. https://www.debian.org/social_contract#guidelines https://www.debian.org/social_contract#guidelines https://www.debian.org/doc/debian-policy/ch-archive.html https://www.debian.org/doc/debian-policy/ch-archive.html

dhimes 8y ago

Would be cool if this was blown out by the courts.