- your code doesn't become GPL, it's GPL compatible

- the restriction are on you code not GPL code you put alongside it

- the restriction clause is on most situations legally meaningless (as a license with restrictions is a new license which happens to also be called GPL but the "no further restriction parts" would apply to the changed license with further restriction :) ), through this situation might be an exception to it

the main question here is how exactly this affects artifacts which are derived from both code bases

now this also loops back to the problem of definition of "derived work" (and how the FSF interpretation is probably NOT (fully) holding up in most EU countries, and yes this now touches on very country specific laws, not generic EU laws)

depending on this if you have an installer/archive which unpacks to a software containing artifacts which clearly are derived only from EUPL and some other artifacts which clearly are derived only from GPL this in practice would be a non issues I think

but what if you have a C header library with EUPL and another with GPL and due to link time optimizations they get so mangled up that under any possible interpretation of derived work it's derived from both ... then I have no idea what the artifact is licensed as ... probably thought the precedence clause GPL and as such no longer has the SaaS protections :/

anyway in most cases the potential legal trouble will lead to many companies only violating it if they would have done so anyway independent of any questionable loop holes, especially given that if the court can't come to a conclusion the intend of the contract writer is taking into considerations.

so if you don't lose money from them violating the license it probably is good enough (as in even if it where GPL, AGPL or similar you don't have much leverage)

and in cases where it commercially matters (e.g. they resell you software as a service while you also do it) you might also have some leverage due to unfair marked practice related laws. But should definitely consult a lawyer.

That is not how I understand it. You cannot simply unilaterally declare a license GPL compatible if it fundamentally isn't. The FSF is crystal clear that is does not consider the EUPL GPL compatible.

"By itself, it has a copyleft comparable to the GPL's, and incompatible with it." [1]

The trick the EUPL tries to pull off to make it work anyways is relicensing. What they call "outbound compatibility" is more similar to codified and enforced dual licensing than license compatibility in the traditional sense.

It only works if your code becomes GPL licensed and not merely compatible. That is where in my opinion the argument put forward in the EU commentary about the EUPL (and brought into discussion here in bcye's comment) breaks down.

"the restriction are on you code not GPL code you put alongside it"

The restrictions are on the users and outside the five exceptions outlined in the GPL and therefore not allowed under GPL. Same reason we need the AGPL as a separate license and cannot tack its additional clause onto the regular GPL as an additional restriction.

[1] https://www.fsf.org/blogs/licensing/european-union-public-li...

which is irrelevant

idk. why people thing it's a good idea to quote an organization as an authoritative source which

- has a long track record of very biased, and sometimes outright wrong, interpretations of what licenses mean in context of EU law

- and of systematically refusing to recognize many situations where it was shown their interpretation is wrong

- and in general ignoring the subtle but (for code licensing) far reaching differences between how law tends to work in EU countries and how it works in the US. Lets not even speak about countries with even more diverging legal systems.

- has political interest in the EUPL not being compatible (and to be clear I don't mean US politics, but like they have their ideals and goals and the EUPL really doesn't fit in them well as it can be seen as taking stewardship of free software licensing away from them, sure they never had that stewardship strictly speaking, but they do often act as if)

Like some things the FSF tends to systematically ignore in their arguments (in no particular order):

- the automatic license termination clause on contract term violations is void, as automatic termination clauses are illegal in all (most?) EU countries in all (most?) contexts. While in general good, this accidentally massively reduces the leverage someone has to enforce GPL and co.

- the "no further restrictions" part is in many legal contexts meaningless (through not the EUPL context)

- EU law doesn't have "viral" Licenses. It has a lot of clauses to promote software interoperability. Starkly oversimplified it can be saied that a lot of protections (including copyright and DRM) are either reduced or outright removed from interfaces. (still oversimplified) Due to this , a license can't just apply constraints on other software interfacing with it. It doesn't matter which mean of interfacing was used. Both static and dynamic linking are just means of interfacing software no different then a stdio pipe from a legal POV! Also license clauses can't overwrite this law, so it doesn't matter if the GPL says it works different it doesn't (in the EU). And that is VERY different to what the FSF claims how the GPL works. That doesn't mean a linking does never create derivative works, it can, it just doesn't do so in all situations. This is especially true if the software interfacing with your software is for accessibility. (^1)

- the link you posted about the FSF statement about the EUPL contains multiple factual wrong things and wording a lawyer would find badly choosen. Like EUPL does not allow re-licensing. What it allows is similar, sure, but not relicensing. It only applies to GPLv2 & GPLv3, not a hypothetical GPLv4, you can't do the trick they describe, actually doing that trick will most likely be judged as a form of contract hacking which can make your situation worse then "just" a contractual breach of a license term. (The exact details depend on the country tho.)

Honestly I'm not sure if their statements come from a unhealthy form of US centrism or other biases. But the moment you speak about copyright law in the EU I can only recommend to not at all trust any statements the FSF makes.

(^1): This funnily lead to a company officially creating hacks for games as "accessibility tools" (which to some degree they are). They still got sued into oblivion but the core of the law suite was unfair marked practices and legal/contract hacking as in their claim of producing "accessibility tools" is just make believe even through some minority of people might use them like that.