I think you're 90% right in what you say here and in following comments, but I think you're skewing things in a way where I end up disagreeing with your conclusions.
> Here is the rub: free software permits unconditional use.
Why are you using the term "free software" here, when it has a well-defined meaning that is very much what you get with copyleft and the GPL and not what you get with BSD/MIT? I think you mean "open source", specifically open source as opposed to free software. Your terminology makes a lot of the conversation here unnecessarily hard to follow.
> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
I don't see the AGPL as the antithesis of OSS at all, even though I agree that it is activated by a condition that pertains to use, not just redistribution. But that's the mechanism, not the goal. Just like the GPL relies on copyright law to have its effect, AGPL relies on what you're calling a EULA. (I don't disagree, and to me a EULA is a contract, but whether it's exactly the right term doesn't seem important.) GPL isn't alone in depending on copyright; the BSD license does just as much.
> Running a program, as a service or not, isn't redistribution. It is use.
Agreed, but "redistribution" vs "use" is a mechanism argument. The intended purpose of the GPL was to allow a developer to write software whose future evolution is freely shared. The redistribution mechanism doesn't even accomplish this 100%: in particular it allows branchless twigs off of the evolutionary tree as long as they are indeed branchless (i.e., not distributed to anyone else who makes further modifications). That goes counter to the goal of free software, but is an acceptable loss because those twigs are irrelevant to the rest of the evolutionary tree.
But there's a loophole here when the GPL is applied to server software: if the software only runs server-side, then the redistribution mechanism no longer works. You could modify your copy, and give that modified copy to someone else who also modifies it. You would have to share your modifications with that person, but not to anyone else. Your twig can grow branches. Neither of you are redistributing the software to anyone else, so you aren't bound by the GPL to make your changes available to anyone else, and certainly not to the original authors.
The AGPL attempts to plug that hole using an extra mechanism: adding a restriction saying that you have to make your changes available not only if you're redistributing the software, but also if users are talking to the running code[1].
> This is no different from Adobe, Apple, Microsoft, ... identifying people using their software in ways they don't like, and crafting their EULA terms to turn those activities into a license violation.
Sure. Those same companies depend on copyright law as well. But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like; its purpose is wholly concerned with the evolution of the software and therefore the changes being made to it. That purpose is achieved via the mechanism of adding conditions based on usage.
> suppose that some government service website is using AGPL software. What do you gain by downloading the software and running your own instance? That's not where your data is; you can't use that cloned instance to communicate with the service agency.
That is correct. AGPL does not solve this problem. If you're locked into a service, then having the full version of the AGPLed code does you very little good. That is described as "Service as a Software Substitute (SaaSS)" in the AGPL explainer at https://www.gnu.org/licenses/why-affero-gpl.html
The free software folks had to punt on that problem. They "solve" it by saying: don't use those services. Which is hardly a satisfying answer, but nothing else is currently possible. Any solution would require regulation and legislation (eg data portability laws).
> I understand the social problem that the AGPL is trying to combat, whereby visitors are held captive by saas applications over which they have no visibility or control.
Incorrect (see above). Though I think some AGPL supporters did (and probably still do) think that the AGPL helps with that. I guess it does, in trivial cases.
> Also one issue is that the AGPL doesn't actually solve anything. Visitors having the source code to my evil saas platform doesn't solve the problem that they're locked to it. It doesn't solve the problem that I can change the code at any time and they cannot. Or that I can shut it down and wipe out their data, or share it with third parties. An AGPL conforming application also need not provide visitors with any way to export their data.
This is all correct. Well, except the first sentence, because the AGPL does solve one thing: it ensures that the evolution of a piece of software is freely accessible.
Or maybe two things, though the second was not part of the original intention afaik: the ElasticSearch/OpenSearch situation. The original author develops something that their business depends on and does not want to end up competing with their own code. AGPL ensures that nobody can take their code, add some features to it, and then win their customers with the enhanced proprietary version. The original author will at least have access to all of the modifications that anybody makes, so competition will need to be on a different basis.
[1] It seems like it would have been more straightforward to keep the AGPL conditions based on redistribution, and say that you have to release your changes to everyone if you distribute your version to anyone. Would that even work? You'd have a transaction from A->B that induces a requirement on A->the world. But it would have avoided making conditions based on use rather than just redistribution. I dunno, IANAL. It would still allow someone to change the version that they're running without releasing the changes, unlike the current AGPL, but that's no worse than the situation with GPL'd client-side software and doesn't seem like a problem worth solving.