tl;dr: I’m asking the biggest users of the LVFS to sponsor the project.
The Linux Foundation is kindly paying for all the hosting costs of the LVFS, and Red Hat pays for all my time — but as LVFS grows and grows that’s going to be less and less sustainable longer term. We’re trying to find funding to hire additional resources as a “me replacement” so that there is backup and additional attention to LVFS (and so that I can go on holiday for two weeks without needing to take a laptop with me).
This year there will be a fair-use quota introduced, with different sponsorship levels having a different quota allowance. Nothing currently happens if the quota is exceeded, although there will be additional warnings asking the vendor to contribute. The “associate” (free) quota is also generous, with 50,000 monthly downloads and 50 monthly uploads. This means that almost all the 140 vendors on the LVFS should expect no changes.
Vendors providing millions of firmware files to end users (and deriving tremendous value from the LVFS…) should really either be providing a developer to help write shared code, design abstractions and review patches (like AMD does) or allocate some funding so that we can pay for resources to take action for them. So far no OEMs provide any financial help for the infrastructure itself, although two have recently offered — and we’re now in a position to “say yes” to the offers of help.
I’ve written a LVFS Project Sustainability Plan that explains the problem and how OEMs should work with the Linux Foundation to help fund the LVFS.
I’m aware funding open source software is a delicate matter and I certainly do not want to cause anyone worry. We need the LVFS to have strong foundations; it needs to grow, adapt, and be resilient – and it needs vendor support.
Draft timeline, which is probably a little aggressive for the OEMs — so the dates might be moved back in the future:
APR 2025: We started showing the historical percentage “fair use” download utilization graph in vendor pages. As time goes on this will also be recorded into per-protocol sections too.
JUL 2025: We started showing the historical percentage “fair use” upload utilization, also broken into per-protocol sections:
JUL 2025: We started restricting logos on the main index page to vendors joining as startup or above level — note Red Hat isn’t sponsoring the LVFS with money (but they do pay my salary!) — I’ve just used the logo as a placeholder to show what it would look like.
AUG 2025: I created this blogpost and sent an email to the lvfs-announce mailing list.
AUG 2025: We allow vendors to join as startup or premier sponsors shown on the main page and show the badge on the vendor list
APR 2025: Start showing over-quota warnings on the per-firmware pages
APR 2025: Turn off detailed per-firmware analytics to vendors below startup sponsor level
AUG 2026: Turn off access to custom LVFS API for vendors below Startup Sponsorship level, for instance:
/lvfs/component/{}/modify/json/lvfs/vendors/auth/lvfs/firmware/auth
DEC 2026: Limit the number of authenticated automated robot uploads for less than Startup Sponsorship levels.
Comments welcome!
Seems very reasonable.
As a general concept I think it makes sense, and 1¢/download is a pretty fantastic price for the level of reach LVFS provides.
I am concerned that this might impact the ability to attract new companies that don’t currently use LVFS.
Some mitigations I can think of might be:
* Associate tier loses access to analytics only when over the quota
* Explicitly list onboarding support as a benefit for higher tiers
Good idea about the analytics, I’ll do that. For the onboarding, I’m planning to continue to do that for all account levels, as before.
I’ve been talking to an employee at an American company that my employer is working with about this change yesterday and showed them this blog post. Their impression was that they likely won’t be providing files to LVFS if it causes additional expenses.
Apparently, anything else than publishing updates on the company website, providing a driver update kit for client machines, or using Windows’ update mechanism is seen as a ‘developer fad’. My contact was under the impression that using WHQL doesn’t incur any fees. Apparently, they practically only compile and sign a .zip from their Chinese supplier (?).
So I have mixed feelings towards this now. From my endeavors with Chinese manufacturers, I know they tend to want to avoid any additional R&D work on a product after launch, so my guess is that others are going to be thinking similarly. Were other measures considered? Linux distributions tend to have their own infrastructure. Allowing public mirrors of centrally sourced and signed packages is kind-of a core principle of Linux software distribution. Why not something like for LVFS that to bring down hosting costs?
A monolith mega-service with no alternative is somewhat not-so-Linux, imho. FOSS in general prefers running on sponsorships and voluntary contributions. I can see the reasons behind this development but at the same time I’m afraid this could turn out to be a step away from general firmware update availability for Linux.
Thanks for that insight. I guess what the blog post is missing is that you can ship nearly a million firmware updates per year without any nagging from me whatsoever. If you’re shipping more systems than that then you can afford to contribute $10K to the project that’s making it possible. One correction; using Windows Update is expensive — one vendor wouldn’t disclose how much but said it was “6 figures per SKU” — but there are heavy discounts available with WHQL certification and presumably arranged by CEOs playing golf.
If a vendor is not providing any R&D after launch it’s also incredibly insecure; even shipping new microcode or CSME is a requirement these days to avoid critical security issues.