The article seems pretty clear that the LGPL is too weak compared to the EUPL for this author, and one of the main concerns is the "SaaS loophole" which I assume would be addressed by the AGPL but also seems addressed by the EUPL.

▲

brainwad 2 days ago | parent [-]

But the EUPL itself says that derivative works may be distributed under the LGPL instead, as long as those works are derived from both a EUPL and LGPL parent. This seems kinda trivial to abuse and the author should have noticed this clause if that was their main concern.

▲

LoganDark 2 days ago | parent | next [-]

Huh, that's a pretty massive loophole. Pretty much makes the whole license irrelevant.

	▲	2 days ago \| parent [-]
		[deleted]

▲

layer8 2 days ago | parent | prev [-]

The EUPL obligations still apply, unless they specifically conflict with the other license. There is some dispute on how exactly that is to be interpreted, but hopefully it will be clarified in version 1.3: https://interoperable-europe.ec.europa.eu/collection/eupl/di...

A “conflict” here is intended to mean that following some EUPL obligation (such as publishing the derived source code) wouldn’t be allowed under the alternative license.

▲

brainwad 2 days ago | parent [-]

I don't understand how that's supposed to work - then you can't distribute under the compatible license; only under a weird hybrid of that license and non-conflicting EUPL terms. Seems to defeat the purpose of the compatibility clause?

	▲	layer8 2 days ago \| parent [-]
		Yes, I agree, it’s unclear how the EUPL requirements would propagate for a composite work that gets relicensed under the compatible license, without changing the latter.