> 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.
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.
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...