I'm not 100% knowledgeable on the topic but wasn't the issue with (A)GPL that even linking libraries in the runtime to your project would mean that your project can't be proprietary?
> This makes no obstacle for linking Code A with another software component (Code B) that could be proprietary. There is no kind of “viral effect” resulting from the EUPL licence, in so far linking is done for interoperability. The portions of Code A that are strictly necessary for interoperability may be reproduced in Code B without copyright infringement. The resulting “A-B solution”, which could be commercial, will include the two modules under their relevant licences. This is resulting from interpreting European law and case law[1].
To paraphrase, EUPL would be the LGPL of AGPL? LGPL where "distribution" also means "distributing the output trough a webpage".
One of the major advantages of LGPL is that users can link their own modified libraries, so that analogy doesn't hold all the way, but linking is permitted and non-viral.
I'm not 100% knowledgeable on the topic but wasn't the issue with (A)GPL that even linking libraries in the runtime to your project would mean that your project can't be proprietary?
With EUPL this doesn't seem to be the case:
From https://joinup.ec.europa.eu/collection/eupl/news/eupl-and-pr...
> This makes no obstacle for linking Code A with another software component (Code B) that could be proprietary. There is no kind of “viral effect” resulting from the EUPL licence, in so far linking is done for interoperability. The portions of Code A that are strictly necessary for interoperability may be reproduced in Code B without copyright infringement. The resulting “A-B solution”, which could be commercial, will include the two modules under their relevant licences. This is resulting from interpreting European law and case law[1].