The AGPL revels in legal uncertainty and UX destroying demands (see FSFs "an agpl reverse proxy must first serve a notice it's AGPL before proxying onward").
I find the EUPL is a much better replacement for what a lot of people expect the AGPL to be, with the added benefit of being compatible with a bunch of other licenses by yielding when specific clauses intersect.
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
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.
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)
I find the EUPL is a much better replacement for what a lot of people expect the AGPL to be, with the added benefit of being compatible with a bunch of other licenses by yielding when specific clauses intersect.