Please stop with this FUD. AGPL is written by lawyers and well understood by other lawyers.
I worked with IP/software license lawyers and AGPL works just fine.
I worked with IP/software license lawyers and AGPL works just fine.
* Most people in free software: The FSF wrote it, therefore it's fine, because the FSF are trustworthy when it comes to freedom%. All server open source projects should use it, it'll magically protect us from the SaaS loophole, and there is nothing to worry about if you're not an evil corporation.
* Most every big corp: the AGPL is a ginormous can of worms and we aren't touching it with a 1 mile pole. Nope. Stay away.
Guess what? Reality is in between those two extremes. The problems with the AGPL are widely underreported in the free software world, and almost nobody has taken a close look at its wording and what it really means. "Leave it to the lawyers" but then nobody ever actually goes and asks a lawyer for a clean take on it.
We should do better. The FSF has done a terrible job of educating people on exactly what the AGPL requires and how it interacts with typical free software project development and deployment workflows. If you haven't asked a lawyer about this then maybe you should think twice before slapping it on your project. Relicensing after the fact is a very costly ordeal.
% The FSF, through their "Respects your Freedom" hardware rubber-stamping program and its absolutely broken requirements, which actively encourages reduction in user freedom, makes it much harder to detect hidden proprietary backdoors, and hurts projects that are actually aiming for maximum openness, have amply proved that they are not infallible and are not to be trusted without careful review of their policies and projects. I can go into a whole different tangent about this, but my point is, don't treat the FSF as the good guys by default. Look at what it is they're doing exactly and all of its consequences.
I guess when you say "has absolutely not been evaluated by people who should care," it's because you think anyone short of Yale isn't a real lawyer. Those jokers and clowns from Harvard....
It sounds like you are angry with the FSF, not sure why.
As for your claims: RYF rubber stamping? RYF reduces user freedom? RYF makes it harder to detect hidden proprietary backdoors? None of these statements make a lot of sense. You're going to need to provide a whole lot more information to back them up.
https://twitter.com/marcan42/status/1040626210999431168?s=19
TL;DR the FSF's RYF program is designed to allow inaccessible, un-auditable, immutable blobs - because they know that if they didn't, nothing would ever get certified (everything has at least some microcode or ROM of some sort, e.g. the USB sound cards they've meaninglessly certified as RYF). By doing this, they encourage companies to make their blobs inaccessible, immutable, and un-auditable in order to get that rubber stamp. And so, we go from having firmware in /lib/firmware or something where it makes engineering sense, to dumping it in some write-protected flash read by a controverted set-up with a side CPU, where the user will never be able to audit or replace it, because that is what they will certify. In their view, proprietary blobs are OK as long as the user can't see them or touch them - but if they can, that's a big no-no. This isn't a hypothetical scenario, as Purism has already gone down this road for the Librem 5, to the detriment of their users' freedom, as well as wasted engineering time and final device cost (that extra flash chip).
Put this way: a device that requires proprietary firmware loaded by an open driver from /lib/firmware is, by any reasonable metric, strictly more free than a device with the same firmware burned into ROM, but the FSF will only certify the latter. Even though you could audit the firmware, guarantee firmware authenticity, or even replace it with a free replacement when it becomes available (or reverse engineer it yourself) in the former case, but not at all the latter.
Meanwhile I have a friend who designed a completely open hardware laptop (think about the significance of that) and the FSF refused to certify it because the main CPU (one of the few with open documentation at all at the time) happened to have a GPU accelerator in it (even though it was not required, you can use it just fine with only framebuffer output) and at the time there were no free drivers, so even if the thing shipped with all open code, they thought users might be "tempted" to install the blob drivers. There was some talk then of getting the manufacturer to permanently disable the GPU in those chips to get certified. So the FSF will certify hardware as long as you remove any features which might be usable with proprietary software. How does this increase user freedom again?
It's all completely bonkers.
I'm somewhat frustrated at the FSF, because it seems that so much of what they do these days is extremist to the point of hurting the free software cause (e.g. some of their campaigns are just embarrassing in how childish they sound). I understand that they don't like proprietary software, but treating it like it's a massive evil upon the world is now way past its expiry date as an advocacy approach; this just makes the whole community look bad. Look at the FSFe if you want a more moderate organization which advocates for these causes without falling into sily behavior like that.
I would disagree. AFAIK you do not need to agree to a separate licence in order to use firmware embedded in hardware, your right to use it is implied from legal ownership of the item.
But if the firmware is distributed independently (like as a part of a Linux distribution), then there are legal complications. The firmware licence must allow redistribution - some do not and then OS contains just script to download it from vendor webpage, which is super awkward, has privacy issues and may force you to accept some vendor conditions. Even if it allows redistribution, it may have some conditions that precludes it from being part of Linux distribution for practical reasons (e.g. advertising clause). And it forces the third party to accept such non-free licence in order to have the right to redistribute it (as a part of Linux distribution).
So it creates plenty of logistical and legal issues for users and third parties just to spare some cents on flash.
Note that having embedded flash with firmware does not preclude having ability to load newer firmware from /lib/firmware during boot.
I don't remember the last time I saw one of those firmware download scripts. Vendors aren't dumb, they know they need to allow firmware redistribution and the vast majority allow it without a problematic license.
Having embedded flash with firmware while being able to load newer firmware from /lib/firmware is not a sensible design, as it requires duplicating ROM and RAM. There are three kinds of common devices:
* Those which load firmware from an embedded ROM, which is immutable (except perhaps minor RAM patches)
* Those with embedded flash that can be updated. These wouldn't load firmware from /lib/firmware, they'd instead be updated by a vendor tool that you run just once.
* Those with a firmware RAM that requires firmware upload on startup. These would use /lib/firmware.
Combinations exist, e.g. chips which can boot from RAM or optional external Flash, but that makes the version of the device with external Flash strictly more free expensive and unnecessary if firmware could just be loaded from the host.