4 ms·

> 3) However, don’t forget the text of the EUPL: “Should the Licensee’s obligations under the Compatible License conflict with his/her obligations under this (E

by bcye 1y ago

> 3) However, don’t forget the text of the EUPL: “Should the Licensee’s obligations under the Compatible License conflict with his/her obligations under this (EUPL) License, the obligations of the Compatible License shall prevail”. So there is double coverage, managing license conflicts and giving priority to the compatible license in such cases. 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. Presumably, it does close the loophole, though it's not very clear-cut. https://interoperable-europe.ec.europa.eu/collection/eupl/discussion/ultimately-how-copyleft-eupl https://interoperable-europe.ec.europa.eu/collection/eupl/di...

bramhaag 1y ago
I interpreted the conflict clause differently (explicit clause vs no clause = a conflict), but I can understand this interpretation as well. If I understand correctly, the derived work would be distributed under the Combined License (say, GPLv3). How can these additional obligations be enforced if they are not part of the license the combined work is distributed under? In other words, I believe that when it says GPLv3 on the tin, I am meant to comply with the GPLv3, not some additional obligations enforced by a different license. But perhaps the situation is more nuanced than that?
- palata 1y ago
  Does it say GPLv3 on the tin, or does it say "Compatible with GPLv3"? If you mix BSD and MIT code, the result doesn't suddenly become one or the other, but rather a combination of both, right?
  - bramhaag 1y ago
    > Does it say GPLv3 on the tin, or does it say "Compatible with GPLv3"? As per [1], it says GPLv3 on the tin. > If you mix BSD and MIT code, the result doesn't suddenly become one or the other, but rather a combination of both, right? The two pieces of code retain their original license, but you can distribute the combined work under just BSD. [1] https://interoperable-europe.ec.europa.eu/collection/eupl/licence-compatibility-permissivity-reciprocity-and-interoperability https://interoperable-europe.ec.europa.eu/collection/eupl/li...
  - dathinab 1y ago
    yes and that is always true for code but the situation for artifacts produced from the combinations of code under different licenses is messy in many ways (not just related to this cases)
- dathinab 1y ago
  yes, but it's really unclear like I wouldn't even rely on the "no further restrictions" clause being valid/legally binding and due to how it works pretty much any previous case trying to enforce it I'm aware of failed (but on a technicality _not_ applying here). (As an example for a invalid clause, the automatic contract voiding on violation clause is not valid in some(all?) EU countries!) and then the definition of derived work, especially in the EU and with GPLv2, is much less ... clear ... then what the FSF likes to claim. so I think you really would need to ask a lawyer in any situations where it does matter
weinzierl 1y ago
That's actually a brilliant insight I had not on my radar. Reading other EU sources seems they strongly support your view. What I don't quite understand though: It's true that the GPL does not have the additional obligations and therefore there is no conflict, but wouldn't the additional obligations be against the "you may not impose further restrictions" of the GPL?
- dathinab 1y ago
  it should be fine as: - 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.
dathinab 1y ago
maybe there might be a conflict due to GPL not "allowing any future extension/restrictions" but this does provide future restrictions but then you code doesn't "become GPL" and GPL also has a compatibility clause and doesn't require other code to be GPL licensed, just to comply with certain constraints so it should be a non issue so I guess it should be fine (also funny side fact, if you take the GPL license then add a clause/restriction it's still valid as the the "no future restrictions" clause if applying to the GPL _with your changes_ because that is the license you have, only if you make a license which basically says "this code is GPL licensed (link to GPL) and following restrictions comply" instead of "this is a GPL with modifications" license does it matter))

by bcye 1y ago

bramhaag 1y ago

I interpreted the conflict clause differently (explicit clause vs no clause = a conflict), but I can understand this interpretation as well. If I understand correctly, the derived work would be distributed under the Combined License (say, GPLv3). How can these additional obligations be enforced if they are not part of the license the combined work is distributed under? In other words, I believe that when it says GPLv3 on the tin, I am meant to comply with the GPLv3, not some additional obligations enforced by a different license. But perhaps the situation is more nuanced than that?

palata 1y ago
Does it say GPLv3 on the tin, or does it say "Compatible with GPLv3"? If you mix BSD and MIT code, the result doesn't suddenly become one or the other, but rather a combination of both, right?
- bramhaag 1y ago
  > Does it say GPLv3 on the tin, or does it say "Compatible with GPLv3"? As per [1], it says GPLv3 on the tin. > If you mix BSD and MIT code, the result doesn't suddenly become one or the other, but rather a combination of both, right? The two pieces of code retain their original license, but you can distribute the combined work under just BSD. [1] https://interoperable-europe.ec.europa.eu/collection/eupl/licence-compatibility-permissivity-reciprocity-and-interoperability https://interoperable-europe.ec.europa.eu/collection/eupl/li...
- dathinab 1y ago
  yes and that is always true for code but the situation for artifacts produced from the combinations of code under different licenses is messy in many ways (not just related to this cases)
dathinab 1y ago
yes, but it's really unclear like I wouldn't even rely on the "no further restrictions" clause being valid/legally binding and due to how it works pretty much any previous case trying to enforce it I'm aware of failed (but on a technicality _not_ applying here). (As an example for a invalid clause, the automatic contract voiding on violation clause is not valid in some(all?) EU countries!) and then the definition of derived work, especially in the EU and with GPLv2, is much less ... clear ... then what the FSF likes to claim. so I think you really would need to ask a lawyer in any situations where it does matter

weinzierl 1y ago

That's actually a brilliant insight I had not on my radar. Reading other EU sources seems they strongly support your view. What I don't quite understand though: It's true that the GPL does not have the additional obligations and therefore there is no conflict, but wouldn't the additional obligations be against the "you may not impose further restrictions" of the GPL?

dathinab 1y ago
it should be fine as: - 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.

dathinab 1y ago

maybe there might be a conflict due to GPL not "allowing any future extension/restrictions" but this does provide future restrictions but then you code doesn't "become GPL" and GPL also has a compatibility clause and doesn't require other code to be GPL licensed, just to comply with certain constraints so it should be a non issue so I guess it should be fine (also funny side fact, if you take the GPL license then add a clause/restriction it's still valid as the the "no future restrictions" clause if applying to the GPL _with your changes_ because that is the license you have, only if you make a license which basically says "this code is GPL licensed (link to GPL) and following restrictions comply" instead of "this is a GPL with modifications" license does it matter))