4 ms·

Looks very interesting. It clarifies a lot of things that for example the GPL leaves unsaid, due to the different legal framework. And it is good that it explic

Looks very interesting. It clarifies a lot of things that for example the GPL leaves unsaid, due to the different legal framework. And it is good that it explicitly calls out the legal jurisdiction it sits under (EU). It's good that it has been written in multiple languages to aid acceptance across the EU. What I like most of all is the listing of compatible licences.if I understand correctly this would enable you to combine GPL and EUPL software and publish the new software under the GPL. Would be nice to see reciprocation so the new software could also be published under the EUPL.

trueismywork 1y ago
The compatability clause is what it makes it useless though, because someone could take your EUPL and convert it to GPL, so EUPL software dies but GPL lives.
- tsimionescu 1y ago
  Sure, just like the BSD and MIT and Apache licenses died, since they allow people to take the software and distribute it under the GPL.
  - trueismywork 1y ago
    No, there's a difference. BSD, MIT and Apache (permissive licenses) are generally used when the provider doesnt care how the end result is used. So, even if other people relicense their code containing Apache licensed part, it doesnt change the business model of that code. In contrast, affero style copyleft licenses are used often specifically to support a business model which allows contributors to take changes from other people back into their code. And an uncaring party can take EUPL code, relicense it under AGPL and now, the original party cannot use the AGPL code. Linus made the same argument for not having GPL 2.0 or later for linux kernel.
    - deleted 1y ago
      [deleted]
- adev_ 1y ago
  That does not seem to be the case > 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. They do mention explicitly "Derivative works", meaning you can not just convert an EUPL software component to GPL and call it a day. To my understanding: If you do include an EUPL component inside a GPLv3 project and it is allowed. But the component itself stay under EUPL. (I would appreciate the confirmation of a lawyer from EU, I am not one).
  - pmontra 1y ago
    IANAL but that could mean that if I take the code of EUPL project Work and I fork it as Libre Work and add a very minor and useless feature that uses another work licensed with some GPL license (not difficult because I can pick the dependency by license,) I have a derivative work that I can distribute under GPLv2. However it seems strange that they didn't think about that. Maybe it's only a bad choice of words, which is equally strange.
    - adev_ 1y ago
      > However it seems strange that they didn't think about that. Maybe it's only a bad choice of words, which is equally strange. I think it is just a different intend. To my understanding, the EUPLv1.2 is structured as a weak copy-left license in the spirit of the MPLv2 but with a major effort on license compatibility. Its quite well explained here: https://interoperable-europe.ec.europa.eu/collection/eupl/licence-compatibility-permissivity-reciprocity-and-interoperability https://interoperable-europe.ec.europa.eu/collection/eupl/li... The intend seems to never be a "strong license" that enforce "strong copyleft" like the GPLv3 / AGPL everywhere. It is more to give a license under which you can create a project that blend a lot of different component under different licenses (GPL, MPL and co) without requiring an army of lawyer to check the compatibility of this mess. That is currently immensely valuable in academic software and in large international collaborations. It also clarify the License contamination behavior over Linking at European Level which is very welcome, because it is frankly speaking, a mess, with license like LGPL.
- Scandiravian 1y ago
  I'm not sure that's true My understanding is it's possible to license either new contributions to a project under GPL, with the original contributions keeping EUPL or you can license a derivative work under GPL, though you still have to comply with the EUPL in regards to the original work (meaning the SaaS loophole will remain closed)
graemep 1y ago
> t clarifies a lot of things that for example the GPL leaves unsaid, due to the different legal framework Such as what? > And it is good that it explicitly calls out the legal jurisdiction it sits under (EU). Offputting if you are not in the EU. > It's good that it has been written in multiple languages to aid acceptance across the EU. Yes, but it looks like its designed primarily for use by the EU itself. It says: > The main objective of the European Commission is to distribute widely and promote the use of software owned by itself and other European Institutions under an Free/Open Source Licence conform to European law requirements. Its great that the EU commission is committing to open source, but only EU institutions rather than a broader push for FOSS in the EU. > Would be nice to see reciprocation so the new software could also be published under the EUPL Unlikely, because no one other than an EU agency would want some of the clauses. The click to agree thing in particular.
- Ragnarork 1y ago
  If you don't like the scope of the license especially with regards to the legal jurisdiction it sits under, then don't use it, don't use software under EUPL license, and call it a day?
- steve_gh 1y ago
  >> And it is good that it explicitly calls out the legal jurisdiction it sits under (EU). >Offputting if you are not in the EU. Knowing the jurisdiction that the licence sits under is a huge advantage, because it tells you the legal framework you are operating under. That means that a lawyer should be able to advise you on what meets the license terms based on settled law and precedent. That's much cheaper than fighting it out in court.
  - graemep 1y ago
    Not compared to the jurisdiction being your local one.
    - steve_gh 1y ago
      I disagree. If your local jurisdiction does not deal with software licences regularly, then how they chose to interpret them is unknown. So you may end up in an expensive court fight. With a known jurisdiction building a solid corpus of precedent and case law then there are fewer unknowns. It's really the same as corporate incorporation - you chose a jurisdiction with a solid corpus of precedent and case law to avoid court cases. that's why most folk chose Delaware for the US.
KolibriFly 1y ago
Most licenses just assume an Anglo-American legal context, which doesn't always translate cleanly to EU law

trueismywork 1y ago

The compatability clause is what it makes it useless though, because someone could take your EUPL and convert it to GPL, so EUPL software dies but GPL lives.

tsimionescu 1y ago
Sure, just like the BSD and MIT and Apache licenses died, since they allow people to take the software and distribute it under the GPL.
- trueismywork 1y ago
  No, there's a difference. BSD, MIT and Apache (permissive licenses) are generally used when the provider doesnt care how the end result is used. So, even if other people relicense their code containing Apache licensed part, it doesnt change the business model of that code. In contrast, affero style copyleft licenses are used often specifically to support a business model which allows contributors to take changes from other people back into their code. And an uncaring party can take EUPL code, relicense it under AGPL and now, the original party cannot use the AGPL code. Linus made the same argument for not having GPL 2.0 or later for linux kernel.
  - deleted 1y ago
    [deleted]
adev_ 1y ago
That does not seem to be the case > 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. They do mention explicitly "Derivative works", meaning you can not just convert an EUPL software component to GPL and call it a day. To my understanding: If you do include an EUPL component inside a GPLv3 project and it is allowed. But the component itself stay under EUPL. (I would appreciate the confirmation of a lawyer from EU, I am not one).
- pmontra 1y ago
  IANAL but that could mean that if I take the code of EUPL project Work and I fork it as Libre Work and add a very minor and useless feature that uses another work licensed with some GPL license (not difficult because I can pick the dependency by license,) I have a derivative work that I can distribute under GPLv2. However it seems strange that they didn't think about that. Maybe it's only a bad choice of words, which is equally strange.
  - adev_ 1y ago
    > However it seems strange that they didn't think about that. Maybe it's only a bad choice of words, which is equally strange. I think it is just a different intend. To my understanding, the EUPLv1.2 is structured as a weak copy-left license in the spirit of the MPLv2 but with a major effort on license compatibility. Its quite well explained here: https://interoperable-europe.ec.europa.eu/collection/eupl/licence-compatibility-permissivity-reciprocity-and-interoperability https://interoperable-europe.ec.europa.eu/collection/eupl/li... The intend seems to never be a "strong license" that enforce "strong copyleft" like the GPLv3 / AGPL everywhere. It is more to give a license under which you can create a project that blend a lot of different component under different licenses (GPL, MPL and co) without requiring an army of lawyer to check the compatibility of this mess. That is currently immensely valuable in academic software and in large international collaborations. It also clarify the License contamination behavior over Linking at European Level which is very welcome, because it is frankly speaking, a mess, with license like LGPL.
Scandiravian 1y ago
I'm not sure that's true My understanding is it's possible to license either new contributions to a project under GPL, with the original contributions keeping EUPL or you can license a derivative work under GPL, though you still have to comply with the EUPL in regards to the original work (meaning the SaaS loophole will remain closed)

graemep 1y ago

> t clarifies a lot of things that for example the GPL leaves unsaid, due to the different legal framework Such as what? > And it is good that it explicitly calls out the legal jurisdiction it sits under (EU). Offputting if you are not in the EU. > It's good that it has been written in multiple languages to aid acceptance across the EU. Yes, but it looks like its designed primarily for use by the EU itself. It says: > The main objective of the European Commission is to distribute widely and promote the use of software owned by itself and other European Institutions under an Free/Open Source Licence conform to European law requirements. Its great that the EU commission is committing to open source, but only EU institutions rather than a broader push for FOSS in the EU. > Would be nice to see reciprocation so the new software could also be published under the EUPL Unlikely, because no one other than an EU agency would want some of the clauses. The click to agree thing in particular.

Ragnarork 1y ago
If you don't like the scope of the license especially with regards to the legal jurisdiction it sits under, then don't use it, don't use software under EUPL license, and call it a day?
steve_gh 1y ago
>> And it is good that it explicitly calls out the legal jurisdiction it sits under (EU). >Offputting if you are not in the EU. Knowing the jurisdiction that the licence sits under is a huge advantage, because it tells you the legal framework you are operating under. That means that a lawyer should be able to advise you on what meets the license terms based on settled law and precedent. That's much cheaper than fighting it out in court.
- graemep 1y ago
  Not compared to the jurisdiction being your local one.
  - steve_gh 1y ago
    I disagree. If your local jurisdiction does not deal with software licences regularly, then how they chose to interpret them is unknown. So you may end up in an expensive court fight. With a known jurisdiction building a solid corpus of precedent and case law then there are fewer unknowns. It's really the same as corporate incorporation - you chose a jurisdiction with a solid corpus of precedent and case law to avoid court cases. that's why most folk chose Delaware for the US.

KolibriFly 1y ago

Most licenses just assume an Anglo-American legal context, which doesn't always translate cleanly to EU law