Hacker News Reader

Interesting: https://interoperable-europe.ec.europa.eu/collection/eupl/ho...

> Is the use of a compatible licence a "re-licensing"?

> No. The original code will stay covered by the EUPL. It is the combined work only that could be, when needed, covered by the compatible licence. In this framework, a combined work results from merging functional codes covered by two (or more) different licenses. The simple action of "linking" does not merge functional codes and in such case the various linked parts will keep their primary licences. This is resulting from the European law, since Directive 2009/24/EC states that interfaces (APIs, data structures etc.) needed for making two programs interoperable can be freely reproduced/used in the various source codes, as an exception to strict copyright rules.

> To be legitimate, the use of the compatibility clause must result from necessity: using it for the sole purpose of relicensing a copy of the original work would be a copyright infringement.

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

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?

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?

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

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)

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

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?

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.

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

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

> FSF is crystal clear that is does not consider the EUPL GPL compatible.

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.

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

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.

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

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

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.

AGPL or even GPL is fine. It's just a statement of intent: "artificial scarcity is bad, we want information to be free and those who take from the pile must add to it."

Realistically, open source licenses are legally powerless against corporations and governments, because they can hire more lawyers than you and rewrite the laws for themselves. We shouldn't play their game at all. The terms of open source licenses can be enforced socially. We can boycott, vote against, and shame violators. And we can be lenient towards other open source projects even if they use an incompatible license.

Yeah this is insane. This is basically what was already happening, i.e. cloud companies offering a Redis service under some generic name. It barely slows them down. I can't understand how legal counsel would not have objected to adding this clause, and who would push for such a clause? It effectively removes the innovation from it. Why choose EUPL over GPLv3 if it can just be relicensed?

right now Valkey is a separate project, not just "Redis service under some generic name"

I'm not sure if you're being sarcastic. Valkey is literally a fork of Redis with a generic name.

Valkey is a fork of BSD Redis under a different name. That makes a difference.

It makes a difference in that it allows the cloud providers to monetize Redis without having to deal with the Redis team. Which is fair and in the spirit of the original license of Redis, but don't paint it as some great achievement of open source ethos.

What Redis did by embracing a bad license shouldn't be applauded either. But the problem is that there isn't a great copyleft license that prevents embrace, extend & extinguish of great cloud projects. EUPL might've been it, and this weird clause just kills what would have made it perfect.

Alternatively, maybe redis wouldn't have seen great adoption if it was under any non-compete license.

That is, to be able to be hosted by someone else is a necessary factor in widespread adoption and success.

The open source ethos is to give code that you are allowed to do as you wish with, including forking. The idea that there should only be one canonical project is... just wrong.

It's not about non-compete, it's about copyleft. What's blocking redis and and with them a whole generation of open source based startups from embracing true open source licenses is that there is no copyleft license for the cloud age. GPLv3 is 18 years old by now, and the big cloud providers have captured the OSI to prevent a GPLv4 from ever happening.

The open source ethos is not to give code to do as you wish with. It's to ensure users have control over the software and are not controlled by it.

It's not about blocking competition, it's about levelling the playing field. You are supporting the cause of trillion dollar megacorporations in their campaign of capitalizing on open source software over the backs of passionate trailblazers.

The maintainers of Valkey are being tricked by these companies to continue to develop for a project that can be easily exploited.

EUPL is more of a political/legal compromise than a strong ideological statement