Hacker News Reader

Comment by apt-get | Hacker News Reader

Worth noting that the "escape hatch" clauses in the EUPL that allow converting it into other licenses mean it's only ever as strong as the weakest license it names for such an operation, AKA EPL/MPL/LGPL.

Any actor that wants to mess around with providing a closed extension on a network service can exercise that option with an EUPL codebase, so if you care about that, you're better off explicitly naming the AGPL or whatnot.

EUPL is built for government agencies first, and most of the focus is ensuring that nobody has to worry about mix-and-matching it with other copyleft licenses, plus legal language that covers and harmonizes variations in notions of copyright/patents/intellectual property across EU countries, not so much waging war against hyperscalers. (But it's still great to have around!)

View on HN

You are describing the compatibility clause as if it's settled that the EUPL simply allows you to convert to a compatible license. The compatibility clause is an unfortunate ambiguity, but it's not the intention of the license authors to lose strong copyleft and SaaS loophole protections this way. See for example here [1] [2] [3].

[1] https://interoperable-europe.ec.europa.eu/collection/eupl/di...

[2] https://interoperable-europe.ec.europa.eu/collection/eupl/ho...

[3] https://news.ycombinator.com/item?id=45422512

The way I read all of that is that:

* BigTech can take your EUPL library and write a small wrapper in MPL

* such a wrapper can therefore be used in any project, even a closed one that is a network service.

* however all of that still qualifies as distributing EUPL, and the EUPL core would still need to be made available under EUPL (whether modified or not).

Saying that since I have an MPL wrapper then all the code is MPL is not allowed.

So you can't just copy all the code and change the license to MPL.

This is basically AGPL without virality and anti-tivo, correct?

On the face of it, no it doesn't say that. It just says the combined work can be MPL. Then someone can take that MPL work, and distribute it without source code because the MPL allows that. It explicitly says any conflict between the EUPL and the MPL shall be resolved in favor of the MPL.

This isn’t the intent, and will hopefully be fixed/clarified in version 1.3: https://interoperable-europe.ec.europa.eu/collection/eupl/di...

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

> But as none of the compatible licenses come into conflict with the EUPL *by prohibiting the essential points* of publication of the source code and coverage of remote distribution (closing the SaaS loophole), these obligations, that are the core of the "reciprocal" condition, persist for the derivatives concerned.

aka: the compatible licenses do not put additional restrictions, so no, it is not MPL.

also, from the license:

> this Distribution or Communication can be done under the terms of this Compatible Licence..

So you are allowed distribution, not relicensing.

To simplify It seems to me that:

* GPL will automatically make something GPL.

* EUPL will automatically make something selectively dual-licensing. parts EUPL, parts whatever.

Also do note that EUPL is the first license to explicitly state that any issues fall under EU(Belgium) law, so EU has the last say on its license.

I read a few dozen comments to see if I could get an answer to this in the thread, but it does appear to be a case where we're highlighting one of the risks of picking up a new license: folks don't agree on how to interpret it.

I'm very curious why the author didn't simply use AGPL, but I haven't done a deep dive on the text of the EUPL, so maybe that's the next step.

EDIT: Went to go research this. First thing I learned is the license has been around since 2007. It was updated in 2017. So maybe scratch my comment about it being a new license!

Reply on news.ycombinator.com