[_cenw]

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.

[josephcsible]

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

Can you link to that requirement?

[_cenw]

https://www.gnu.org/licenses/gpl-faq.html#AGPLProxy

[josephcsible]

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

[yencabulator]

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

[_cenw]

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.

[spaceribs]

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?

[_cenw]

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)

[spaceribs]

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