5 ms·

Perhaps someone else can clarify this, but I've been cautious about using this license instead of AGPLv3, because even though it includes this clause to close t

Perhaps someone else can clarify this, but I've been cautious about using this license instead of AGPLv3, because even though it includes this clause to close the SaaS loophole: ‘Distribution’ or ‘Communication’: any act of selling, giving, lending, renting, distributing, communicating, transmitting, or otherwise making available, online or offline, copies of the Work or providing access to its essential functionalities at the disposal of any other natural or legal person. It still allows someone to relicense your work under GPL-2.0-only and GPL-3.0-only (amongst others): ‘Compatible Licences’ according to Article 5 EUPL are: — GNU General Public License (GPL) v. 2, v. 3 Both these licenses have no such clause. Does this not make the attempt to close the SaaS loophole void? edit: some words from the FSF it gives recipients ways to relicense the work under the terms of other selected licenses, and some of those—the Eclipse Public License in particular—only provide a weaker copyleft. Thus, developers can't rely on this license to provide a strong copyleft. https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2 https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2 To me, this seems very poorly thought out. I see no reason to use this license over AGPL (or even GPL).

tinco 1y ago
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?
- arccy 1y ago
  right now Valkey is a separate project, not just "Redis service under some generic name"
  - tinco 1y ago
    I'm not sure if you're being sarcastic. Valkey is literally a fork of Redis with a generic name.
    - Aeolun 1y ago
      Valkey is a fork of BSD Redis under a different name. That makes a difference.
      - tinco 1y ago
        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.
        arccy 1y ago
        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.
        tinco 1y ago
        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.
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...
treffer 1y ago
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 1y ago
  > 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 1y ago
    > 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/news/why-eupl-not-viral-l https://interoperable-europe.ec.europa.eu/collection/eupl/ne... [1] https://interoperable-europe.ec.europa.eu/collection/eupl/how-use-eupl https://interoperable-europe.ec.europa.eu/collection/eupl/ho...
smartmic 1y ago
Interesting: https://interoperable-europe.ec.europa.eu/collection/eupl/how-use-eupl 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.
- deleted 1y ago
  [deleted]
KolibriFly 1y ago
EUPL is more of a political/legal compromise than a strong ideological statement
deleted 1y ago
[deleted]
txrx0000 1y ago
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.

tinco 1y ago

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?

arccy 1y ago
right now Valkey is a separate project, not just "Redis service under some generic name"
- tinco 1y ago
  I'm not sure if you're being sarcastic. Valkey is literally a fork of Redis with a generic name.
  - Aeolun 1y ago
    Valkey is a fork of BSD Redis under a different name. That makes a difference.
    - tinco 1y ago
      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.
      - arccy 1y ago
        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.
        tinco 1y ago
        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.

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

treffer 1y ago

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 1y ago
> 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 1y ago
  > 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/news/why-eupl-not-viral-l https://interoperable-europe.ec.europa.eu/collection/eupl/ne... [1] https://interoperable-europe.ec.europa.eu/collection/eupl/how-use-eupl https://interoperable-europe.ec.europa.eu/collection/eupl/ho...

smartmic 1y ago

Interesting: https://interoperable-europe.ec.europa.eu/collection/eupl/how-use-eupl 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.

deleted 1y ago
[deleted]

KolibriFly 1y ago

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

deleted 1y ago

[deleted]

txrx0000 1y ago

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.