For agpl specifically I believe it’s due to muddy waters surrounding the “derivative work” clause. Some companies have traditionally bent the definition (eg insinuating that api calls result in larger application fall under combined work) and it’s never been tested in court so understandably the lawyers do the lawyer thing and tell you not to use it

Yeah, but even stepping back there, lawyers are paid to prevent companies from entering those muddy waters as a risk to their profits.

Profit isn't a concern to someone who wishes to publish open source software, in fact you could say Open Source is an inherently socialist venture (your socializing the tools/means to do something).

The AGPL3 makes it more difficult for others with probably more means to profit on that work, so it's a net benefit to the folks who actually write code (and a detriment to those who would wish to exploit it).

Right so as long as food and shelter is not a concern AGPL is v good license!

Yep! I'd say 95% of open source is subsidized by those thriving rather than surviving, having the education/equipment/access/free-time to deliver open source software is a product of privilege and abundance.

Not only some companies - API calls being linking also seems to be the opinion of the FSF.

I mean I always though of AGPL as network-aware GPL so that makes sense to me. IANAL

I recall someone pointing out, AGPL only affects offering the same core functionality over network. So you cant monetize exposing as is. But you can use as a backend component. Lot of people miss that. I did too. IANAL.

That's the ambiguity I mentioned. Nobody actually knows. MinIO for instance thinks you're wrong.

garage a competitor with a rust code based think thats legal.

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.

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.