While I agree that it's legally murky in some respects, that seems like an opportunity (and a benefit to the writer of the OSS code) for a dialog between the maintainer and the user of AGPL code to ensure compliance.

Why would you want to open a bunch of loopholes for very specific and complex cases?

EUPL compatibility is not exactly "opening a bunch of loopholes". It's yielding to a very specific list of licenses, to very specific conditions that exclusively make the resulting license more strict (e.g. combining with AGPL basically turns it into an AGPL licensed work)

Ah, I'll admit I know a lot less about the EUPL, I'll do some further reading on the subject.

> see FSFs "an agpl reverse proxy must first serve a notice it's AGPL before proxying onward"

Can you link to that requirement?

That says a proxy could use a landing page to do that, not that it has to do it that way.

The underlying requirement of providing source to users is firm, though. How else will a reverse proxy prominently make a statement to networked users?

> prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source

https://www.gnu.org/licenses/agpl-3.0.html

Yes, correct. If this is their best shot at a solution, it doesn't bode well for their interpretation of the AGPL allowing any UX-friendly version of this, let alone a normally functioning API Gateway.