[treffer]

Compatibility as I understand it means "mixing this in a project is OK".

This is the case if the 2 license aren't at odds. Usually one license is stricter and you have to adhere to that one for the combined work.

A counter-example is GPLv2 and Apache license. Those 2 are incompatible. This was fixed with GPLv3 and you can often upgrade to GPLv3.

So no, this won't allow you to relicense as GPLv2. But you can use GPLv2 code.

This is especially relevant if you have such code redistribution clauses.

[bramhaag]

  > So no, this won't allow you to relicense as GPLv2. But you can use GPLv2 code.

I don't think your interpretation is correct:

   If the Licensee Distributes or Communicates Derivative Works or copies thereof based upon both the Work and another work licensed under a Compatible Licence, this Distribution or Communication can be done under the terms of this Compatible Licence

To me, this means that the combined work (e.g. EUPL + GPLv2) may be distributed under the "Compatible License" (GPLv2, in this case), but if you were to distribute only the EUPL-licensed work, you would have to distribute it under EUPL.

Besides, I do not think GPLv2 allows you to distribute a combined work under EUPL, for it is listed as GPL-Incompatible. The combined work would have to be distributed under a license compatible with both EUPL and GPLv2.

[badsectoracula]

> Besides, I do not think GPLv2 allows you to distribute a combined work under EUPL, for it is listed as GPL-Incompatible. The combined work would have to be distributed under a license compatible with both EUPL and GPLv2.

AFAICT there is one aspect that seems to trip people when they come from a US-centric view of these licenses (including FSF): IIRC, in EU law a program can be made up of multiple licenses without each one affecting the other parts because the "virality" aspect of GPL (and similar aspects) does not work under the legal framework (because of how what is considered "combined work" under EU). There is an article[0] about why EUPL is not viral (both by choice and because of EU law) that explains it.

The How to use EUPL[1] document also spells it out:

---

But the definition of derivative works depends on the applicable law. If a covered work is modified, it becomes a derivative. But if the normal purpose of the work is to help producing other works (it is a library or a work tool) it would be abusive to consider everything that is produced with the tool as "derivative". Moreover, European law considers that linking two independent works for ensuring their interoperability is authorised regardless of their licence and therefore without changing it: no "viral" effect."

---

Note that in practice since 99.9% of the software in EU also goes outside the EU, including the US, the above doesn't matter much for (A)GPL software so even people (and companies) inside EU treat (A)GPL virality like in US. It is only when it comes to software meant to be used within EU alone (like government software) where the distinction matters.

[0] https://interoperable-europe.ec.europa.eu/collection/eupl/ne...

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

[weinzierl]

That is true and an important aspect.

It still does not explain the cognitive dissonance of the EUPL.

1. Source Merging or Statically Linking

Since the EU recognizes that these form derivative works the compatibility provisions in the EUPL are useless. At least as long as they are not interpreted as re-licensing.

2. Dynamically linking or IPC or network requests

If the EU is serious that dynamically linking is not derivative the compatibility provisions in EUPL are not necessary.