Did you notice that there is some tension between „vendors cannot distribute“ and „pretty much everyone except us distributes, including vendors with real legal teams“?
An explanation that‘s more detailed than „read the license“ would be really nice. And the submission title remains pure clickbait.
"Unless expressly permitted under the Agreement, You will not, and will not allow any third party to
(i) use, copy, distribute, sell or offer to sell the Software or associated documentation;
(ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software;
(iii) use or make the Software available for the use or benefit of third parties; or
(iv) use the Software on Your products other than those that include the Intel hardware product(s),
platform(s), or software identified in the Software; or
(v) publish or provide any Software benchmark or comparison test results."
Ta for the link. That is quite a discussion. The first thread is priceless (it turns out that grauenwolf isn't quite as authoritative as they first appear - fancy!)
Never underestimate how keen people can become about something they have paid £1,000s for. How on earth could a DBMS like MySQL/MariaDB or PostgreSQL possibly compare to the mighty Oracle money generator or MSSQL ... errrr ... money generator.
Here is the thing, at least in the case of database software, the people that are competent to set up a benchmark correctly are fairly rare. The people that have the budget for the hardware are even more rare. The last thing the world needs is for the web to be polluted by so many incompetent "benchmarks" performed by the clueless that you can't find the authoritative information that you need to do your job.
Take a wild guess about how much memory and how many disk spindles it takes to get a TPC benchmark on a modern server to be CPU limited. Take a guess as to how many weeks of engineering time it takes to perform and validate the benchmark after getting a pile of hardware delivered to your lab. The average blogger writing 3 posts a week ain't gonna do it.
I'm on the fence about the benchmarks but I think this is a generic broad brush to sweep away the parent's comment given the real concerns they've presented and you've chose to not address.
Do you really thing any agreement that involves silence is censorship NDAs included?
Sure, it's easy to simply say: sucks to be you! Especially to "community bullies" like Oracle. Even just between semi-competing open source projects benchmarks can be so bad they border on libelous.
Oracle has just enough budget to hire someone knowledgeable to engage in the discussion, pointing out the issues and their fixes, possibly even linking the benchmarks that were (in their view) properly performed. One good engineer. Compare with the legal fees required to draft such an appalling, scared and knowingly guilty clause as "you can't talk about how our product performs despite having paid for it." This really needs to be treated with total derision, and utter contempt. It's an approach that has earned that response for it's sheer laziness before even beginning to measure it against any ethical standards.
Oracle are just an awful company in every dimension. This, is just like most everything else they do in that it reinforces the reputation they earned for themselves.
Well, most times I'd like to know how a badly configured X compares with badly configured Y, on <random hardware> - because that's usually how things are run.
But this doesn't mean having the vendor control publication is going to get you any benchmarks that are better. We can predict pretty easily that the benchmarks they publish will be skewed in their favour.
On the other hand, we can't predict what solutions society comes up with for dealing with incompetent benchmarks. For example, you say professional bloggers would do lousy jobs, but this is exaclty the kind of things that neckbeard hobbyist bloggers would take upon themselves and do excellent jobs at.
That or other solutions could emerge, but the whole point of censorship is to prevent that.
> Here is the thing, at least in the case of database software, the people that are competent to set up a benchmark correctly are fairly rare. The people that have the budget for the hardware are even more rare. The last thing the world needs is for the web to be polluted by so many incompetent "benchmarks" performed by the clueless that you can't find the authoritative information that you need to do your job.
If these apparently incompetent people running the benchmarks are also the incompetent people creating the schema's and queries out in the wild then the benchmarks are still worthwhile.
I want to know what performance I can expect, not what I can expect when the environment is highly tuned by rare experts that will never touch any of the systems I have to deal with.
I worked for a competitor and we had similar verbiage. It's there to prevent "XXX is a 10 million times faster than YYY." We actually gave everyone permission if they both asked and allowed us to review their methodology to make sure they weren't doing anything horrifically wrong (benchmarking is hard).
AMD doesn't distribute microcode updates for consumer processors, only Epyc, so it's kind of a mixed bag. They expect consumer processors to get microcode updates via BIOS vendors.
Pretty much all high-performance processor designs are affected by some Spectre variant or other, as speculative execution is pretty near universal. IBM is making firmware patches for POWER9 available, with at least some level of mitigation (though not for some older POWER models, which they've desupported).
(Besides, it's not as if Intel is uniquely good at dealing with these sorts of vulnerabilities. The reverse, if anything -- meltdown was a particularly nasty variant which seems to have primarily affected Intel processors, and not even other manufacturers' x86 variants.)
Only preproduction firmware was affected. Mitigations were implemented in firmware/Linux prior to shipping, and are actually superior to "mitigated" x86.
Before POWER9 shipped (but after the last silicon respin), the processor was vulnerable to both Meltdown and Spectre. IBM determined that this could be mitigated via firmware and kernel changes without another respin.
AIUI, it was determined that for intra-process Spectre mitigation in userspace, recompiling everything to use retpolines and modifying firmware to knacker the branch predictor, etc. in a way that mitigated Spectre had equivalent performance losses. So rather than make people recompile everything with retpolines, the firmware modification option was chosen.
This yields a highly conservative Spectre mitigation erring on the side of security rather than performance.
By comparison, Intel/AMD have chosen not to mitigate intraprocess Spectre by default; it has been made the responsibility of application developers to mitigate intraprocess Spectre via retpolines if desired... it essentially shifts the spotlight for performance losses from the vendors to the developers, giving the vendors an escape from having their patches show huge performance losses. But of course, most people aren't shipping software with retpolines, so in practice, the x86 vendors have basically chosen not to mitigate intraprocess Spectre.
POWER9's firmware-based intraprocess mitigations can be disabled at boot if desired (leaving kernel and interprocess Spectre mitigations and Meltdown mitigations in place), providing a level of protection and performance comparable to "mitigated" x86.
> Unfortunately, that release is undistributable (refer to the new "license" file that was added by Intel to the microcode data file pack version 20180807).
> "Intel has been made aware of the issue and pestered by just about everyone, and should get it straightened up soon."
Sounds like someone in the legal department screwed up, and are being slow to respond to the issue (it's been ~2 weeks). This is unfortunate, but, well, legal departments aren't used to being on the critical path to time-sensitive distribution of security vulnerability mitigations, and the time sensitivity may not have been adequately explained to them.
While looking for AMD desktops, found Dell Optiplex 5055 barebone enterprise desktop with Ryzen (1) Pro 1700X CPU 8 core / 16 threads for about $700 with Ubuntu Linux. Requires a phone call to order for some reason?
That's likely going to be the case with any Optiplex system from Dell. The Optiplex line is intended for large organizations (commerical, government, educational, etc.) that are going to order many systems so they want you to go through their sales platform rather than sell directly.
The purpose of the AMD models is to keep Intel on their toes and get better bulk discounts out of them. Dell doesn't actually want to sell AMD product and complicate their production process.
I worked in several large organizations before, and it was always: give me WWW order printout, and send to organization wide email.
One might have thought they will streamline the process after so many years. After all ordering is as much choosing, as it is making it to fit the budget.
I have been subbed to this bug since the beginning, and when I saw it come up, I was hoping that it _wouldn't_ hit the HN front page, because right now the bug does not have very much information in it. I'm not saying that details and discussion don't exist, just that they're not in the bug.
Because there's not much info in the bug, there isn't much to have a discussion about, unless someone is able to provide information that isn't already in the bug. And, given the audience of HN, saying "License terms are getting in the way" isn't really detailed enough.
What I think is interesting about the license is, it's actually two licenses. Or, a license and a license framework. You'll see what I mean in a moment.
Reading through the license, it seems to me (although I am not a lawyer) that Intel tried to carve out distribution permission. Specifically in Section 2:
> 2. LIMITED LICENSE. … Intel grants to You a … license …, under Intel's copyrights (subject to any third party licensing requirements), to…
(So much preamble…)
> … (i) reproduce the Software only for Your own internal evaluation, testing, validation, and development of Intel-based products and any associated maintenance thereof; …
Sounds good to me. It seems like this (particularly the "associated maintenance" part) covers the necessary testing/packaging work.
> … (ii) reproduce, display, and publicly perform an object code representation of the Software, only when integrated with and executed by an Intel-based product, subject to any third party licensing requirements; …
Reading this, I started to think "Wait, does this mean that the microcode could only be packaged up, distributed to, and mirrored by systems running Intel chips? But no, that's not true, because of the next point.
> … (iii) distribute an object code representation of the Software, provided by Intel, through multiple levels of distribution, …
OK, the files in the tarball are either text, or object code, so that's good.
> … solely as embedded in or for execution on an
Intel-based product and subject to these license terms, …
Hmmmmm, well, the "or for execution on an Intel-based product" would seem to give us permission to distribute, regardless of the hardware used to do the distribution, since the microcode will only be executing on Intel CPUs.
"Subject to these license terms" could be a problem, but the `intel-microcode` package is already in the non-free part of the Debian repo.
> … and if to an end user, pursuant to a license agreement with terms and conditions at least as restrictive as those contained in the Intel End User Software License Agreement in Appendix A hereto.
Hmmmmmmmmmmmm. Does this mean that the `intel-microcode` installer would have to pop-up a license acceptance during package installation?
A quick note here: Section 3 ("LICENSE RESTRICTIONS") does have a distribution restriction, but that restriction is loosened by the caveat "Unless expressly permitted under the Agreement…".
There is one more restriction, which @walterbell mentioned:
> … (v) publish or provide
any Software benchmark or comparison test results;
This is interesting, though. This restriction does not appear in Appendix A, the terms that end users should agree to. So, does that mean that this restriction only applies to the Debian project, as they are the ones who downloaded the software from Intel's site for repackaging? Or, does the phrase "and subject to these license term...
My confusion is who is a 3rd party under this agreement? Are users not 3rd parties? How can a distribution be responsible for and have any power over users, if the first two parties are Intel + distribution, and the 3rd party is the user?
I do find hilarious the "don't download this until you've downloaded and read and agreed to the agreement!" (paraphrased) clause at the top.
As a reminder to everyone discovering here that Debian is very careful about licensing, please honor the request they made in the linked discussion to give Intel time to address their concerns without swarm-attacking Intel with direct contact attempts over this. Debian explicitly is asking the crowd not to source here.
Intel's spokesman isn't saying "ignore the license, distribution is fine, I promise" - he's pointing out the clause in the license which is intended to allow redistribution.
A single clause doesn't make a legal agreement. It only allows redistribution given other conditions placed on it directly and indirectly by the rest of the license and other documents that relate.
It's entirely possible that redistribution is allowed in very limited circumstances that do not include Debian's distribution model. The Intel spokesman's lack of understanding of Debian's context doesn't mean Debian's mistaken.
Your second sentence is inappropriate — as an outsider to Debian and its legal evaluations, you have no standing to make a statement on behalf of Debian based solely on Intel’s public comment on Twitter.
If and when Debian Legal concurs with the interpretation Intel asserts, then it is fine to say it is “addressed”. Until then, it is not okay for you to cite a statement from Intel as relevant in any way whatsoever to Debian and their position. That’s for Debian to judge and provide.
Have you read the rest of the document? That clause does allow redistribution, but according to Appendix A, redistribution is allowed (in unmodified, binary form) only for personal use.
Actually, that's Imad Sousou of Intel making 1 Twitter comment, followed up by several people making the same points as made elsewhere in this very discussion (q.v.), all of which have gone unanswered by Imad Sousou so far.
The unmentioned context here is that Debian is stricter in how they handle binary firmware than most distributions. I believe they refuse to distribute any not under a free software license, most others will ship binary blob firmware.
That's not completely true. Debian does allow what they call "non-free" software, with limitations (see [1]). In particular, searching for Debian packages with "firmware" in the name[2] will show alot of non-free. This does cause consternation in at least some free-software groups[3].
Yes, Debian is stricter in how they handle everything, including binary blobs. No, they do not refuse to distribute 'any not under a free software license' (there are contrib and non-free repos which allow for this) Where other distros often say 'whatever, we'll include it', Debian acts as a very useful canary when things like this occur.
I don't agree that it's unmentioned context: Debian is currently distributing prior releases of the firmware, Intel released new firmware and changed something in the terms, and the Debian packagers have a problem with the new terms. If anything the unmentioned context is that all too often distros/people just blindly accept changes in license terms where the Debian packagers actually read and evaluate license terms and don't just rubber stamp them. It's useful to everyone that someone is paying attention, even if one disagrees with the Debian position on a given issue.
Intel CPUs without firmware updates because of redistribution limitations? How can Intel make that mistake? Intel, please, reconsider that, for your own good.
In what world does it actually make sense for Intel to use such a license with microcode firmware applicable to improving the security of desktop computers?
Is this just an attempt to limit distribution during a teething period, in case there are bugs in the new microcode?
I wish that security updates consisted only of "Hi there, if you're [GUID] running [VERSION], then you should be apply update [SHA-256 SUM], which hopefully will get you to [LATER_VERSION]. [Cryptographically] Signed, [SOMEONE YOU TRUST]." That assertion could easily live in a kilobyte of data. Then if you cared about that message, you could go anywhere -- vendor site, Bittorrent, IPFS, your classmate's computer via your local network, even the attacker trying to own you -- to get the multi-megabyte/gigabyte update. If the hash matches, apply it. Otherwise, ignore it.
The (slightly contrived) relevance to this post is whether Intel should get to decide whether its updates are redistributable. They should definitely get to declare which updates are authentic. But it seems reasonable that the remaining decisions should be up to the owner of the hardware, who has to deal with the consequences of its software/firmware not being up to date.
As a stopgap measure until the licensing issues are straightened out, you can build an updated version of the package yourself rather easily. What's below should more or less work to generate an updated intel-microcode package starting from Debian's intel-microcode-3.20180703.2 source:
mkdir microcode_src
cd microcode_src
sudo apt-get build-dep intel-microcode
apt-get source intel-microcode
# download microcode-20180807.tgz from Intel
mkdir microcode_new
cd microcode_new
tar xf ../microcode-20180807.tgz
cp intel-ucode/* ../intel-microcode-3.20180703.2/intel-ucode
cd ../intel-microcode-3.20180703.2/debian
cat >> changelog <<EOF
intel-microcode (3.20180807.1manual) unstable; urgency=medium
* manually update to latest Intel microcode package
-- me <my@email.address> Mon, 20 Aug 2018 00:00:00 -0000
EOF
cd ../
debuild -b -uc -us
cd ../
sudo dpkg -i intel-microcode-3.20180807.1manual_amd64.deb
YMMV, use the above at your own risk, understand what you're doing before you do it, etc.
I would rather have Intel redistribute their firmware in easy-to-install packages, trusted and verifiable, if they, for some reason, cannot trust distros package it.
Doing a firmware update from a random untrusted source is an invitation to have a hard-to-detect exploit added to your system.
Full out Pirate Linux currently does not exist, as far as I know. I guess just adding package repositories with dubious licenses would do the same job?
What's truly hilarious about this is that this EULA can't possibly serve any purpose... since Intel microcode blobs are RSA encrypted and signed. Only Intel CPUs can decrypt and consume them, and they can't be modified. It's not like it can be reverse engineered. I have to wonder what exactly Intel is worried people will do with these blobs.
79 comments
[ 2.9 ms ] story [ 160 ms ] threadI read in the bug that other vendors don't have a problem with the license, and I see nothing in detail why Debian might feel otherwise.
3. "You will not, and will not allow any third party to" (iii) "use or make the Software available for the use or benefit of third parties"
An explanation that‘s more detailed than „read the license“ would be really nice. And the submission title remains pure clickbait.
> All right, title and interest in and to the Software
> and associated documentation are and will remain the exclusive property of
> Intel and its licensors or suppliers. Unless expressly permitted under the
> Agreement, You will not, and will not allow any third party to
> (v) publish or provide
> any Software benchmark or comparison test results.
"Unless expressly permitted under the Agreement, You will not, and will not allow any third party to
(i) use, copy, distribute, sell or offer to sell the Software or associated documentation;
(ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software;
(iii) use or make the Software available for the use or benefit of third parties; or
(iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or
(v) publish or provide any Software benchmark or comparison test results."
Full license
https://gist.github.com/fa7012d13ceb0b82521bfac10213ecc6
https://www.reddit.com/r/programming/comments/2mhpwp/postgre...
Never underestimate how keen people can become about something they have paid £1,000s for. How on earth could a DBMS like MySQL/MariaDB or PostgreSQL possibly compare to the mighty Oracle money generator or MSSQL ... errrr ... money generator.
Just in case you wonder whether open source DBMSs should be taken seriously, try reading this: https://postgresweekly.com/ and this: https://mariadb.com/resources/blog
Take a wild guess about how much memory and how many disk spindles it takes to get a TPC benchmark on a modern server to be CPU limited. Take a guess as to how many weeks of engineering time it takes to perform and validate the benchmark after getting a pile of hardware delivered to your lab. The average blogger writing 3 posts a week ain't gonna do it.
It also prevents meaningful benchmarks to be published.
Do you really thing any agreement that involves silence is censorship NDAs included?
Sure, it's easy to simply say: sucks to be you! Especially to "community bullies" like Oracle. Even just between semi-competing open source projects benchmarks can be so bad they border on libelous.
Oracle are just an awful company in every dimension. This, is just like most everything else they do in that it reinforces the reputation they earned for themselves.
On the other hand, we can't predict what solutions society comes up with for dealing with incompetent benchmarks. For example, you say professional bloggers would do lousy jobs, but this is exaclty the kind of things that neckbeard hobbyist bloggers would take upon themselves and do excellent jobs at.
That or other solutions could emerge, but the whole point of censorship is to prevent that.
https://danluu.com/anon-benchmark/
If these apparently incompetent people running the benchmarks are also the incompetent people creating the schema's and queries out in the wild then the benchmarks are still worthwhile.
I want to know what performance I can expect, not what I can expect when the environment is highly tuned by rare experts that will never touch any of the systems I have to deal with.
> If You redistribute this Software, You must reproduce the above > copyright notice and this license with the Software.
> You may not reverse engineer, decompile, or disassemble this Software > or any portion thereof.
Like Intel, they forbid, as much as possible, any reverse engineering. But unlike Intel, they allow redistribution and benchmarking.
(Besides, it's not as if Intel is uniquely good at dealing with these sorts of vulnerabilities. The reverse, if anything -- meltdown was a particularly nasty variant which seems to have primarily affected Intel processors, and not even other manufacturers' x86 variants.)
See https://www.ibm.com/blogs/psirt/potential-impact-processors-...
Before POWER9 shipped (but after the last silicon respin), the processor was vulnerable to both Meltdown and Spectre. IBM determined that this could be mitigated via firmware and kernel changes without another respin.
AIUI, it was determined that for intra-process Spectre mitigation in userspace, recompiling everything to use retpolines and modifying firmware to knacker the branch predictor, etc. in a way that mitigated Spectre had equivalent performance losses. So rather than make people recompile everything with retpolines, the firmware modification option was chosen. This yields a highly conservative Spectre mitigation erring on the side of security rather than performance.
By comparison, Intel/AMD have chosen not to mitigate intraprocess Spectre by default; it has been made the responsibility of application developers to mitigate intraprocess Spectre via retpolines if desired... it essentially shifts the spotlight for performance losses from the vendors to the developers, giving the vendors an escape from having their patches show huge performance losses. But of course, most people aren't shipping software with retpolines, so in practice, the x86 vendors have basically chosen not to mitigate intraprocess Spectre.
POWER9's firmware-based intraprocess mitigations can be disabled at boot if desired (leaving kernel and interprocess Spectre mitigations and Meltdown mitigations in place), providing a level of protection and performance comparable to "mitigated" x86.
> Unfortunately, that release is undistributable (refer to the new "license" file that was added by Intel to the microcode data file pack version 20180807).
> "Intel has been made aware of the issue and pestered by just about everyone, and should get it straightened up soon."
Sounds like someone in the legal department screwed up, and are being slow to respond to the issue (it's been ~2 weeks). This is unfortunate, but, well, legal departments aren't used to being on the critical path to time-sensitive distribution of security vulnerability mitigations, and the time sensitivity may not have been adequately explained to them.
https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-...
https://www.dell.com/en-us/work/shop/desktop-and-all-in-one-...
There's this as well: https://www.dell.com/learn/us/en/19/campaigns/enabling-today... (I found that with "dell amd")
One might have thought they will streamline the process after so many years. After all ordering is as much choosing, as it is making it to fit the budget.
Because there's not much info in the bug, there isn't much to have a discussion about, unless someone is able to provide information that isn't already in the bug. And, given the audience of HN, saying "License terms are getting in the way" isn't really detailed enough.
I encourage you to go to the microcode download at https://downloadmirror.intel.com/28039/eng/microcode-2018080... and actually read the license file. You'll laugh or groan at the first part of the first paragraph:
> DO NOT DOWNLOAD, …
What I think is interesting about the license is, it's actually two licenses. Or, a license and a license framework. You'll see what I mean in a moment.
Reading through the license, it seems to me (although I am not a lawyer) that Intel tried to carve out distribution permission. Specifically in Section 2:
> 2. LIMITED LICENSE. … Intel grants to You a … license …, under Intel's copyrights (subject to any third party licensing requirements), to…
(So much preamble…)
> … (i) reproduce the Software only for Your own internal evaluation, testing, validation, and development of Intel-based products and any associated maintenance thereof; …
Sounds good to me. It seems like this (particularly the "associated maintenance" part) covers the necessary testing/packaging work.
> … (ii) reproduce, display, and publicly perform an object code representation of the Software, only when integrated with and executed by an Intel-based product, subject to any third party licensing requirements; …
Reading this, I started to think "Wait, does this mean that the microcode could only be packaged up, distributed to, and mirrored by systems running Intel chips? But no, that's not true, because of the next point.
> … (iii) distribute an object code representation of the Software, provided by Intel, through multiple levels of distribution, …
OK, the files in the tarball are either text, or object code, so that's good.
> … solely as embedded in or for execution on an Intel-based product and subject to these license terms, …
Hmmmmm, well, the "or for execution on an Intel-based product" would seem to give us permission to distribute, regardless of the hardware used to do the distribution, since the microcode will only be executing on Intel CPUs.
"Subject to these license terms" could be a problem, but the `intel-microcode` package is already in the non-free part of the Debian repo.
> … and if to an end user, pursuant to a license agreement with terms and conditions at least as restrictive as those contained in the Intel End User Software License Agreement in Appendix A hereto.
Hmmmmmmmmmmmm. Does this mean that the `intel-microcode` installer would have to pop-up a license acceptance during package installation?
A quick note here: Section 3 ("LICENSE RESTRICTIONS") does have a distribution restriction, but that restriction is loosened by the caveat "Unless expressly permitted under the Agreement…".
There is one more restriction, which @walterbell mentioned:
> … (v) publish or provide any Software benchmark or comparison test results;
This is interesting, though. This restriction does not appear in Appendix A, the terms that end users should agree to. So, does that mean that this restriction only applies to the Debian project, as they are the ones who downloaded the software from Intel's site for repackaging? Or, does the phrase "and subject to these license term...
I do find hilarious the "don't download this until you've downloaded and read and agreed to the agreement!" (paraphrased) clause at the top.
There even seems to be restrictions on commercial use, so making it illegal to make and sell Debian install media with firmware blobs?
It's entirely possible that redistribution is allowed in very limited circumstances that do not include Debian's distribution model. The Intel spokesman's lack of understanding of Debian's context doesn't mean Debian's mistaken.
If and when Debian Legal concurs with the interpretation Intel asserts, then it is fine to say it is “addressed”. Until then, it is not okay for you to cite a statement from Intel as relevant in any way whatsoever to Debian and their position. That’s for Debian to judge and provide.
[1]: https://www.debian.org/doc/debian-policy/ch-archive.html#the...
[2]: https://packages.debian.org/search?suite=all&arch=any&search...
[3]: https://www.gnu.org/distros/common-distros.en.html
I don't agree that it's unmentioned context: Debian is currently distributing prior releases of the firmware, Intel released new firmware and changed something in the terms, and the Debian packagers have a problem with the new terms. If anything the unmentioned context is that all too often distros/people just blindly accept changes in license terms where the Debian packagers actually read and evaluate license terms and don't just rubber stamp them. It's useful to everyone that someone is paying attention, even if one disagrees with the Debian position on a given issue.
Is this just an attempt to limit distribution during a teething period, in case there are bugs in the new microcode?
The (slightly contrived) relevance to this post is whether Intel should get to decide whether its updates are redistributable. They should definitely get to declare which updates are authentic. But it seems reasonable that the remaining decisions should be up to the owner of the hardware, who has to deal with the consequences of its software/firmware not being up to date.
I would rather have Intel redistribute their firmware in easy-to-install packages, trusted and verifiable, if they, for some reason, cannot trust distros package it.
Doing a firmware update from a random untrusted source is an invitation to have a hard-to-detect exploit added to your system.