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.
> 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.
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?
- 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.
> 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))
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?
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
> 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.
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?
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.
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.
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.
> 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).
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.
> 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.
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.
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.
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)
> 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.
>> 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.
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.
I maybe looking at it from a point of view of being in a legal system (the UK) that I have reasonable confidence in with regard to most civil cases. I always prefer contracts to specify England ans Wales as the jurisdiction, for example.
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?
I had to deal with it for work
a little bit and maybe my conclusions are useful to others, so here they are [1].
- EUPL is closely modeled after GPL. If you take away one thing then that: If you squint hard enough you will see GPL.
- In a sense it is closer to GPLv3.
It has explicit patent related terms. It lacks Tivozation and DRM provisions, so it is not a complete match.
- Beyond what is in the GPL the EUPL tries to be explicit when it comes to license compatibility. EUPL distinguishes between inbound and outbound compatibility and it is very important to be clear when speaking about this.
- Other Copyleft licenses (esp. GPL) are NOT inbound compatible with EUPL.
- GPL (v2 and v3) are outbound compatible besides some other explicitly listed licenses.
The last point is very strange and the biggest quirk in the otherwise pretty boring EUPL. The issue is this: EUPL has some additional restrictions that go beyond GPL. On the other side the GPL does not allow additional restrictions apart from certain precisely defined exceptions ("section 6").
The mechanism the EUPL has chosen to deal with this is that you are legally authorized to switch from EUPL to GPL, and after switching, all the stricter EUPL bits fall away.
[1] I am not a lawyer, consider my vantage being that of an EU startup, also opinions my own, not speaking for my employer.
EDIT: Skimming through the other comments I got the impression that many consider the EUPL closer to the AGPL. The reason I don't see it that way is the mentioned outbound GPL compatibility which renders the additional Affero provisions toothless.
EDIT 2: See bcye's comments which point out an interesting angle that might mean that my views regarding the AGPL issue may be too simplistic.
One interesting reason is that there are no official non-English versions of the GPL at all, the FSF (as it says itself) not having the means to ensure robust legal text in multiple languages, whereas the EUPL has official versions in 23 of the E.U.'s languages, the E.U. very much having the means to produce legal documents in tens of languages.
Martin Tournoi, the developer of GoatCounter, wrote an article explaining why he chose the EUPL licence for GoatCounter. It provides valuable insights and a useful comparison: https://www.arp242.net/license.html
He has modified EUPL (bad idea to modify licenses) so it recreates one of the problems he has with AGPL (that a lot of companies will not use software licensed under it). If anything EUPL is less attractive to those companies if they are outside the EU as it imposes EU jurisdiction.
Other people might see the above as an advantage, as you can dual license and those who do not like AGPL can buy a commercial license.
He has misunderstood the AGPL (there is no requirement to send changes to the original developer, only make them available to users).
His modification of EUPL is to explicitly remove one of his advantages, by reducing compatibility with all but two (AGPL and OSL).
h
It looks like his EUPL is not compatible with the EU's EUPL as a result of that modification, and the only way to mix the two would be to license as OSL or AGPL.
>If anything EUPL is less attractive to those companies if they are outside the EU as it imposes EU jurisdiction.
So then for people who are living inside EU it is a good ideal to use this license instead of AGPL if they don't want their code ended up in some transnational big corp for example?
GoatCounter is an open source web analytics platform available as a free donation-supported hosted service or self-hosted app. It aims to offer easy to use and meaningful privacy-friendly web analytics as an alternative to Google Analytics or Matomo.
>The purpose of the European Commission is first of all to distribute its own software under the licence
The European Commission is the main executive branch of the European Union. The above sentence is like saying "the purpose of the White House is first of all to distribute software".
This is really just a mistranslation. The author's native language seems to be Spanish. The Spanish word propósito can be translated as "purpose" or "intention." Here, it really means "intention."
I was curious about differences between EUPL and GPL Affero, I found the following:
> the EUPL could therefore be described as an “affero-like” licence (AGPLv3).
> The EUPL covers SaaS (Software as a Service): if an internet service provider modifies the licensed software to distribute online services (as Google does), this is “software distribution”.
Does it have the equivalent "anti-Tivoization" requirement of GPLv3?
I found Linus Torvalds' arguments for GPLv2 (vs v3) very compelling, but the SaaS loophole to contributing back seems sort of absurd. Torvalds doesn't get his code changes either.. so I feel he's likely also not thrilled. I'd love to find something that's effectively AGPLv2 (and not v3)
EDIT:
Here:
Nevermind .. it seems to have bizarre relicensing loopholes..
> In the Free Software Foundation's judgment, the added requirement in section 2(d) of Affero GPL v1 made it incompatible with the otherwise nearly identical GPLv2. That is to say, one cannot distribute a single work formed by combining components covered by each license.
> By contrast, the GPLv3 and GNU AGPLv3 licenses include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses.
Maybe what I'm asking doesn't make sense. B/c it requires for for instance GPL to include the ability to be restricted further by the no-SaaS clause. The GPL only allows for AGPLv3. It's explicit
I believe there is a problem/conflict with the networked-software clause and the EUPL's compatibility clause. It allows anyone to fork a project under the GPL license. When someone makes a fork of an EUPL project under the GPL license, they are then bypassing the extra conditions set out in the AGPL. I believe this to be a mistake/loophole in the EUPL. But I am not a lawyer so I really hope an actual legal expert can weigh in on this.
> — ‘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.
Yup. This is a common pattern for official EU pages to link to the various translations of the actual text using the country code. Another example: https://eur-lex.europa.eu/eli/dir/2022/2380/oj
Nor does Y-bar's example from EUR-Lex, where the language list is below the catalogue information. It being right at the top in a banner of hyperlinks with 2-letter codes is not actually a part of the pattern. The E.U. Parliament and E.U. Court of Justice use drop-down menus with the full language names, for example.
Well one is a random directive from 2022 about radio equipment marketing; and the other, hyperlinked by outadoc in the first place, was the very text of the European Union Public Licence version 1.2 as PDF and text/plain formats in 23 languages, with the EUPL version 1.1 as PDF in 22 languages at the bottom of the page.
If you wanted an apt one, instead of a random radio equipment marketing directive, that was specifically EUR-Lex, there's https://eur-lex.europa.eu/eli/dec_impl/2017/863/oj which is the E.U. Commission decision promulgating version 1.2 of the EUPL.
As noted elsethread, neither one, nor the E.U. Parliament nor E.U. Court of Justice, does things exactly the way that Javier Casares does them.
Also note that outadoc wasn't actually asking how to read the text, in the first place. outadoc was pointing out that Javier Casares's unofficial copy here does not anywhere hyperlink (in order to provide a source) to the official europa.eu. WWW site, which outadoc then pointed to. Nor does it hyperlink to the aforelinked E.U. Journal entry.
It took them the entire first section to not mention that it is a _software license_.
In the context of EU regulating stuff, "a license" (at least to me) is not automatically assumed to be with regards to software distribution rights. I get that the naming makes it look similar to the (L)GPL and so on, but that could just be marketing and/or someone trying to associate with known things.
The first paragraph after the main title would have been better if it had a second sentence:
What is the EUPL?
EUPL is an acronym for "European Union Public Licence". It is a software distribution license.
That would (to me) have made it so much more clear, and avoided having to build up confusion while reading until the purpose was revealed.
Not everyone just assumes that a licence that has passed through a E.U. Commission approvals process is a software copyright licence.
That said, this is a personal WWW site of someone named Javier Casares, apparently a system administrator. Any E.U. citizen can rent a eu. subdomain. The E.U.'s own domain is europa.eu. and the E.U. Commission's own blurb gets straight to the point in its first sentence:
It is not a bad association, the GPL is of course fantastic.
I was expecting it to be a software license, but it was (to me) confusing and thus annoying that it wasn't made more clear from the beginning of the text. The entire first section did not specify that it was talking about software, and I think that is important context and should be stated very early.
Looks like it's a thing from 15-20 years ago. I've never come across this license in any project; so it doesn't look like it is widely used. It looks to me like this failed to get a lot of usage.
I was in an EU project around 2007-2008 via Nokia Research. No mention of this license. But at the time they did have a list of licenses that were OK for licensing software. License like GPL, Apache 2.0, etc.
I do not wish to diminish Javier Casares's effort here: but it is nonetheless the case that a system administrator's WWW site about the EUPL is not the primary controlling factor when it comes to adoption of the EUPL, any more than https://www.pastafarismo.es wholly determines the popularity of Pastafarianism. (-:
What stands out is the focus on legal interoperability across the EU, not just code reuse. Makes sense for governments collaborating on digital infrastructure, though I imagine it's a nightmare for developers trying to navigate license compatibility in real-world projects
An AGPL-like license without the enmity that Stallman and GPL have.
IANAL, but I skimmed it and I see:
* a patent grant
* no extra clauses
* static/dynamic linking seems fine with compatible licenses (edit: unclear to me if proprietary can link (edit2: I find articles stating this is not viral and linking is always permitted, but there are section covering "essential functionality" in the license, so shim layers should not be allowed?))
* modifying for SaaS is redistributing
* clear list of compatible licenses (notably excluded: BSD/MIT/Apache)
* you can use both "this version" or "or later"
* trademarks not included
* no liability, except for "willful misconduct or damages directly caused to natural persons". Does not exclude from other law requirements.
If EUPL is the GPL v3 for EU, is there similar one for MIT/ BSD / Apache ?
I think I asked a question about this 10 years ago on HN about MIT / BSD like license that is worldwide accepted, I thought it was Public Domain. Turns out the concept of Public Domain isn't universal. I remember it was Germany or some other EU countries that doesn't have it.
But if GPL / MIT / BSD have been widely accepted for 20+ years worldwide now and counting. Why do we need another one?
If you restrict how users run your software, then it is not free software, by the definition of both the FSF and OSI. An anti-weaponization clause is no different from an anti-commercialism clause in this context.
There are many licenses with mortality clauses but they are general not popular because the ambiguity and "supply chain risk" of having such a license in a dependency tree tends to limit adoption of any projects that use them.
What’s to prevent the Bad Guys from illegally using your code, while the Good Guys cannot and have to settle on an inferior solution to fight the Bad Guys?
Or (now gonna get creative here, to invent counterexamples of why this is not a good idea) one that cannot be used in software that is used to teach children about evolution!
A good step. Would love to see something like this OSI approved and globally used as a next generation reasonable license that protects the next generation of open source software companies.
Once again, the EU coming 30 years later to do something everyone else is doing, and everyone will credit them for some odd reason.
In the 90s, there were dozens (hundreds?) of phone charging ports. A couple of years ago, there were only two. The dozens -> 2 simplifications occurred on the purely free market. And the EU mandated a simplification from 2 -> 1 and gets the credit for the entire simplification.
What is the point of this license? Either the GPL is invalid in the EU, in which case why aren't companies moving to the EU to infringe on the GPL? Or it is valid, in which case a a bunch of EU lawyers were given a bunch of MY money to do nothing of value to anyone.
Whenever something from the EU emerges on HN, whatever that is, a comment exactly like yours is made.
Today it's you, tomorrow someone else.
Always the same "points" and the poster always seems to feel obliged to bring their own misshapen view of history, forgetting that a lot of good changes in this so-called "free market" happened because of the EU.
Sure more tech became popular out of the US but let's not be blinded:
1. This tech isn't/wasn't the only innovative tech ever created
2. A lot of reasons for the popularity has to do with US position over the rest of the world
3. That this same tech has been kept at bay because of the US
I'm not saying the EU is perfect but I prefer its direction over the US, especially when it comes to making legislations which benefits the people rather than multinational corporations.
I simply do not think that the popularity of US tech is due to anything other than the quality of US tech.
I live in Romania, and the people that were rushing to pirate Windows in the 90's after communism fell because they couldn't afford licensing weren't doing so because of any US imposition, but simply because they wanted to use personal computers, and Windows was the best OS for most people at the time for that purpose.
Just like when phones came around they rushed to buy Nokia phones; when smartphones came around they rushed to buy Samsung phones; when they wanted DLSRs they bought Canon and Nikon cameras and now that they want easily transferable digital cash and cheap tech trinkets they opened up Revolut accounts and order stuff off Temu.
Not because of any "influence" or "position" of Finland, South Korea, Japan, the UK or China, but simply because they are the best offer on the market as perceived by consumers.
What tech does Europe lead in? To be fair there are still some fields, like Aerospace (Airbus), Lithography (ASML) or Pharmaceutics (BioNTech). But on the consumer tech market, the phones, laptops and streaming services people want? The EU has no presence. Even the auto industry is going to be eaten up by China, because Europe simply pivoted too late to EVs. I know someone who works at Renault and they're just terrified of the cars that are coming out of China.
I see your point but that stops being true once the bigger companies start stifling competition (both locally and internationally) to become even bigger and more pervasive.
There are European alternatives for many products/services that are currently US-based but they either don't have the same marketing budgets, or international reach or can offer lower prices. All those are often due to first-to-market tied with anti-competitive practices (further tied to governments not having much power against these organisations) which makes these companies move even more to the top. None of that was about better tech but rather everything else.
And sometimes yes, better tech, but let's not fool ourselves into thinking that "better tech" is not somehow tied to more money available to spend on improving such tech. Big capitals being moved around the US has an impact to this tech.
By the way, there are European alternatives Amazon (just not big enough to be international, but many countries have their own version), Microsoft (i.e. Linux), Google (ProtonMail/ProtonDrive , Nextcloud, etc.), AWS (the ones which comes to mind are Upcloud and Hetzner), Android/iOS (Ubuntu Touch)
That was not done by the European Commission. It was a document with no legal power. And it was an acknowledgment of an existing market trend. non-iPhones had already began converging on USB charging (including mini-USB and micro-USB) in the years before.
By the time the EU actually first proposed regulation on the matter, which was only in 2020, there were in effect three ports on the phone market: the Apple Lightning was still used in iPhones, and the rest of the market was undergoing an orderly migration from the cheaper micro-USB port, to the more expensive but better USB-C port.
So yes, the free market was entirely responsible for transitioning from dozens of ports to 3 ports, and would have very likely eventually transitioned to 2 ports. The fact that the EU made recommendation to that effect years ago after the trend had begun that was purely voluntary is an entirely irrelevant datum.
That's not really what happened. The European Commission made gave the manufacturers a choice: they could sit down and come up with standard that they voluntarily accepted to follow or the EC could write the standard and force the manufacturers to follow it [1].
I imagine they would have eventually converged on USB anyway, but when the upcoming rules (or "rules") were announced, you definitely could not count on being able to charge your phone using anyone else's charger (or one of the many that had come with your previous phones).
Counterfactuals are tricky, and we'll never know for sure what might have been, but seeing laptop manufacturers dragging their feet, I really can't see how you could feel so certain that the market would have fixed the mess that existed just as quickly.
... Eh? It's from 2007. Licenses like this weren't at all common at the time; there was the original Affero license, but AGPLv3, the first version to see widespread use, didn't come out until later.
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:
It still allows someone to relicense your work under GPL-2.0-only and GPL-3.0-only (amongst others): 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
https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2To me, this seems very poorly thought out. I see no reason to use this license over AGPL (or even GPL).
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...
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))
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?
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
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?
[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)
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.
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.
EUPL is more of a political/legal compromise than a strong ideological statement
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.
Most licenses just assume an Anglo-American legal context, which doesn't always translate cleanly to EU law
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.
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).
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.
> 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/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.
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.
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.
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)
> 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.
>> 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.
Not compared to the jurisdiction being your local one.
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.
I maybe looking at it from a point of view of being in a legal system (the UK) that I have reasonable confidence in with regard to most civil cases. I always prefer contracts to specify England ans Wales as the jurisdiction, for example.
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?
> > And it is good that it explicitly calls out the legal jurisdiction it sits under (EU).
> Offputting if you are not in the EU.
Why? US law is terrible. You don't want to be ruled by it on pretty much any issue you can avoid.
Fair point. I am not in the US so not looking at it the same way I suppose.
I have lived in a country where I did not prefer the jurisdiction so I can understand.
The US might still be attractive to the licensor because of some aspects of copyright law there.
I had to deal with it for work a little bit and maybe my conclusions are useful to others, so here they are [1].
- EUPL is closely modeled after GPL. If you take away one thing then that: If you squint hard enough you will see GPL.
- In a sense it is closer to GPLv3. It has explicit patent related terms. It lacks Tivozation and DRM provisions, so it is not a complete match.
- Beyond what is in the GPL the EUPL tries to be explicit when it comes to license compatibility. EUPL distinguishes between inbound and outbound compatibility and it is very important to be clear when speaking about this.
- Other Copyleft licenses (esp. GPL) are NOT inbound compatible with EUPL.
- GPL (v2 and v3) are outbound compatible besides some other explicitly listed licenses.
The last point is very strange and the biggest quirk in the otherwise pretty boring EUPL. The issue is this: EUPL has some additional restrictions that go beyond GPL. On the other side the GPL does not allow additional restrictions apart from certain precisely defined exceptions ("section 6").
The mechanism the EUPL has chosen to deal with this is that you are legally authorized to switch from EUPL to GPL, and after switching, all the stricter EUPL bits fall away.
[1] I am not a lawyer, consider my vantage being that of an EU startup, also opinions my own, not speaking for my employer.
EDIT: Skimming through the other comments I got the impression that many consider the EUPL closer to the AGPL. The reason I don't see it that way is the mentioned outbound GPL compatibility which renders the additional Affero provisions toothless.
EDIT 2: See bcye's comments which point out an interesting angle that might mean that my views regarding the AGPL issue may be too simplistic.
Do you have any sense as to why or when I'd pick the EUPL, rather than just going for the GPLv3?
One interesting reason is that there are no official non-English versions of the GPL at all, the FSF (as it says itself) not having the means to ensure robust legal text in multiple languages, whereas the EUPL has official versions in 23 of the E.U.'s languages, the E.U. very much having the means to produce legal documents in tens of languages.
Some (government) clients demand it. Apart from that, no.
On the other hand, if you want GPLv3 anyways the EUPL doesn't hurt much because of its outbound compatibility.
Feels like EUPL was designed more with institutional reuse and legal clarity in mind than with copyleft purity
Martin Tournoi, the developer of GoatCounter, wrote an article explaining why he chose the EUPL licence for GoatCounter. It provides valuable insights and a useful comparison: https://www.arp242.net/license.html
He has modified EUPL (bad idea to modify licenses) so it recreates one of the problems he has with AGPL (that a lot of companies will not use software licensed under it). If anything EUPL is less attractive to those companies if they are outside the EU as it imposes EU jurisdiction.
Other people might see the above as an advantage, as you can dual license and those who do not like AGPL can buy a commercial license.
He has misunderstood the AGPL (there is no requirement to send changes to the original developer, only make them available to users).
His modification of EUPL is to explicitly remove one of his advantages, by reducing compatibility with all but two (AGPL and OSL). h It looks like his EUPL is not compatible with the EU's EUPL as a result of that modification, and the only way to mix the two would be to license as OSL or AGPL.
>If anything EUPL is less attractive to those companies if they are outside the EU as it imposes EU jurisdiction.
So then for people who are living inside EU it is a good ideal to use this license instead of AGPL if they don't want their code ended up in some transnational big corp for example?
They will mostly not use AGPL licensed software either.
EU based big corps will be fine with EU jurisdiction.
> bad idea to modify licenses
Very annoying to modify without renaming.
> GoatCounter
For those that had never heard of it:
GoatCounter is an open source web analytics platform available as a free donation-supported hosted service or self-hosted app. It aims to offer easy to use and meaningful privacy-friendly web analytics as an alternative to Google Analytics or Matomo.
The compatibility clause seems to be confusing several commenters. There is official documentation explaining the license compatibility.
Visually: https://interoperable-europe.ec.europa.eu/collection/eupl/li...
Matrix of licenses: https://interoperable-europe.ec.europa.eu/collection/eupl/ma...
Why is the link pointing to a random dude's random interpretation, instead of the wiki[0], the official website[1], or the official pdf[2]?
[0] : https://en.wikipedia.org/wiki/European_Union_Public_Licence
[1] : https://interoperable-europe.ec.europa.eu/collection/eupl
[2] : https://joinup.ec.europa.eu/sites/default/files/custom-page/...
A fairly poor interpretation at that.. FTA:
>The purpose of the European Commission is first of all to distribute its own software under the licence
The European Commission is the main executive branch of the European Union. The above sentence is like saying "the purpose of the White House is first of all to distribute software".
This is really just a mistranslation. The author's native language seems to be Spanish. The Spanish word propósito can be translated as "purpose" or "intention." Here, it really means "intention."
Why is he using the official EU flag https://eupl.eu/favicon/android-icon-192x192.png (and a knock-off https://eupl.eu/eu.png) if he is not the EU. Why is the website full of tracking.
Gross.
I was curious about differences between EUPL and GPL Affero, I found the following:
> the EUPL could therefore be described as an “affero-like” licence (AGPLv3).
> The EUPL covers SaaS (Software as a Service): if an internet service provider modifies the licensed software to distribute online services (as Google does), this is “software distribution”.
https://interoperable-europe.ec.europa.eu/collection/eupl/ne...
Where can you find a good description..?
Does it have the equivalent "anti-Tivoization" requirement of GPLv3?
I found Linus Torvalds' arguments for GPLv2 (vs v3) very compelling, but the SaaS loophole to contributing back seems sort of absurd. Torvalds doesn't get his code changes either.. so I feel he's likely also not thrilled. I'd love to find something that's effectively AGPLv2 (and not v3)
EDIT:
Here:
Nevermind .. it seems to have bizarre relicensing loopholes..
https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2
Seems a bit insane - esp the two step relicense :
> The EUPL allows relicensing to GPLv2 only and GPLv3 only
So I guess you just relicense to GPLv2 and then do whatever you want
How about the AGPLv2? It’s a thing. (Original Affero GPL).
From what I understand, the original one is "broken"
https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
> In the Free Software Foundation's judgment, the added requirement in section 2(d) of Affero GPL v1 made it incompatible with the otherwise nearly identical GPLv2. That is to say, one cannot distribute a single work formed by combining components covered by each license.
> By contrast, the GPLv3 and GNU AGPLv3 licenses include clauses (in section 13 of each license) that together achieve a form of mutual compatibility for the two licenses.
Maybe what I'm asking doesn't make sense. B/c it requires for for instance GPL to include the ability to be restricted further by the no-SaaS clause. The GPL only allows for AGPLv3. It's explicit
That's only an issue if you want to mix GPL & AGPL, and if you accept the FSF's interpretation (which is hardly clear-cut).
I believe there is a problem/conflict with the networked-software clause and the EUPL's compatibility clause. It allows anyone to fork a project under the GPL license. When someone makes a fork of an EUPL project under the GPL license, they are then bypassing the extra conditions set out in the AGPL. I believe this to be a mistake/loophole in the EUPL. But I am not a lawyer so I really hope an actual legal expert can weigh in on this.
I'm not a lawyer and have little experience reading legal text. I can't find the text of the license saying SaaS is covered. Can you point it out?
The EUPL isn't as explicit as AGPL.
> — ‘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.
Isn’t that the whole point of AGPL?
For people interested the Interoperable Europe Portal offers very detailed documentation on using and interpreting this license: https://interoperable-europe.ec.europa.eu/collection/eupl
Do you know if there is any work on newer version of the licence that would make it more explicit?
I don't see the actual source of the text mentioned on this non-official website, which makes it confusing.
https://interoperable-europe.ec.europa.eu/collection/eupl/eu...
It's not entirely clear, above the "What is the EUPL" headline are links to the license text in each language.
You click the language you want at the top of the webpage, and it takes you to the text of the license. For example, https://eupl.eu/1.2/en/
Yup. This is a common pattern for official EU pages to link to the various translations of the actual text using the country code. Another example: https://eur-lex.europa.eu/eli/dir/2022/2380/oj
You could have chosen a more apt page for an official E.U. example.
Like https://interoperable-europe.ec.europa.eu/collection/eupl/eu... as given above. (-:
That doesn't use the same pattern of linking languages by code in the header, however
Nor does Y-bar's example from EUR-Lex, where the language list is below the catalogue information. It being right at the top in a banner of hyperlinks with 2-letter codes is not actually a part of the pattern. The E.U. Parliament and E.U. Court of Justice use drop-down menus with the full language names, for example.
* https://www.europarl.europa.eu/about-parliament/en/parliamen...
* https://www.europarl.europa.eu/about-parliament/cs/parliamen...
The headlined page, as was pointed out, is just some system administrator's own WWW site, moreover.
What’s the difference? They both follow the same pattern. What am I missing?
Well one is a random directive from 2022 about radio equipment marketing; and the other, hyperlinked by outadoc in the first place, was the very text of the European Union Public Licence version 1.2 as PDF and text/plain formats in 23 languages, with the EUPL version 1.1 as PDF in 22 languages at the bottom of the page.
If you wanted an apt one, instead of a random radio equipment marketing directive, that was specifically EUR-Lex, there's https://eur-lex.europa.eu/eli/dec_impl/2017/863/oj which is the E.U. Commission decision promulgating version 1.2 of the EUPL.
As noted elsethread, neither one, nor the E.U. Parliament nor E.U. Court of Justice, does things exactly the way that Javier Casares does them.
Also note that outadoc wasn't actually asking how to read the text, in the first place. outadoc was pointing out that Javier Casares's unofficial copy here does not anywhere hyperlink (in order to provide a source) to the official europa.eu. WWW site, which outadoc then pointed to. Nor does it hyperlink to the aforelinked E.U. Journal entry.
It is not an official EU page
It took them the entire first section to not mention that it is a _software license_.
In the context of EU regulating stuff, "a license" (at least to me) is not automatically assumed to be with regards to software distribution rights. I get that the naming makes it look similar to the (L)GPL and so on, but that could just be marketing and/or someone trying to associate with known things.
The first paragraph after the main title would have been better if it had a second sentence:
That would (to me) have made it so much more clear, and avoided having to build up confusion while reading until the purpose was revealed.It isn't only a software license, though it does seem to be primarily aimed at that.
One of the compatible licenses is specifically: "Creative Commons Attribution-ShareAlike v. 3.0 Unported (CC BY-SA 3.0) for works other than software"
I don’t understand. GPL is also a software license. Why is that bad association? What were you expecting this to be?
E.U. regulations cover all sorts of licences, from driving licences
* https://eur-lex.europa.eu/legal-content/EN/TXT/?&uri=CELEX:3...
through the Dessenheim, Sierentz, Dannemarie, Staffelfelden, and Seebach licences
* https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
to navigability licences.
* https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A...
Not everyone just assumes that a licence that has passed through a E.U. Commission approvals process is a software copyright licence.
That said, this is a personal WWW site of someone named Javier Casares, apparently a system administrator. Any E.U. citizen can rent a eu. subdomain. The E.U.'s own domain is europa.eu. and the E.U. Commission's own blurb gets straight to the point in its first sentence:
* https://commission.europa.eu/about/departments-and-executive...
It is not a bad association, the GPL is of course fantastic.
I was expecting it to be a software license, but it was (to me) confusing and thus annoying that it wasn't made more clear from the beginning of the text. The entire first section did not specify that it was talking about software, and I think that is important context and should be stated very early.
Looks like it's a thing from 15-20 years ago. I've never come across this license in any project; so it doesn't look like it is widely used. It looks to me like this failed to get a lot of usage.
I was in an EU project around 2007-2008 via Nokia Research. No mention of this license. But at the time they did have a list of licenses that were OK for licensing software. License like GPL, Apache 2.0, etc.
Nothing on this page says what the license does or any reason why anyone should use it. So it's kinda unsurprising nobody adopted it.
I do not wish to diminish Javier Casares's effort here: but it is nonetheless the case that a system administrator's WWW site about the EUPL is not the primary controlling factor when it comes to adoption of the EUPL, any more than https://www.pastafarismo.es wholly determines the popularity of Pastafarianism. (-:
What stands out is the focus on legal interoperability across the EU, not just code reuse. Makes sense for governments collaborating on digital infrastructure, though I imagine it's a nightmare for developers trying to navigate license compatibility in real-world projects
Wonderful!
An AGPL-like license without the enmity that Stallman and GPL have.
IANAL, but I skimmed it and I see:
* a patent grant
* no extra clauses
* static/dynamic linking seems fine with compatible licenses (edit: unclear to me if proprietary can link (edit2: I find articles stating this is not viral and linking is always permitted, but there are section covering "essential functionality" in the license, so shim layers should not be allowed?))
* modifying for SaaS is redistributing
* clear list of compatible licenses (notably excluded: BSD/MIT/Apache)
* you can use both "this version" or "or later"
* trademarks not included
* no liability, except for "willful misconduct or damages directly caused to natural persons". Does not exclude from other law requirements.
If EUPL is the GPL v3 for EU, is there similar one for MIT/ BSD / Apache ?
I think I asked a question about this 10 years ago on HN about MIT / BSD like license that is worldwide accepted, I thought it was Public Domain. Turns out the concept of Public Domain isn't universal. I remember it was Germany or some other EU countries that doesn't have it.
But if GPL / MIT / BSD have been widely accepted for 20+ years worldwide now and counting. Why do we need another one?
This website is not sponsored or endorsed by the European Commission or any other institution, body or agency of the European Union.
I wish there was a public licence that stated something like: This software cannot be used for weapons or any weapon development activities.
I imagine that many missiles, drones and other such devices use free software. I wouldn't want any of my software to be part of these weapons.
If you restrict how users run your software, then it is not free software, by the definition of both the FSF and OSI. An anti-weaponization clause is no different from an anti-commercialism clause in this context.
There are many licenses with mortality clauses but they are general not popular because the ambiguity and "supply chain risk" of having such a license in a dependency tree tends to limit adoption of any projects that use them.
What’s to prevent the Bad Guys from illegally using your code, while the Good Guys cannot and have to settle on an inferior solution to fight the Bad Guys?
Or one that cannot be used in fossil fuel industry.
Or (now gonna get creative here, to invent counterexamples of why this is not a good idea) one that cannot be used in software that is used to teach children about evolution!
[flagged]
It’s worth mentioning that this has nothing to do with the European Union, as mentioned in the footer:
> This website is not sponsored or endorsed by the European Commission or any other institution, body or agency of the European Union.
To clarify, it is the linked site has nothing to do with the EU, but the license itself (EUPL) has:
https://commission.europa.eu/about/departments-and-executive...
https://interoperable-europe.ec.europa.eu/collection/eupl
A good step. Would love to see something like this OSI approved and globally used as a next generation reasonable license that protects the next generation of open source software companies.
It already is OSI approved (and isn't new): https://opensource.org/license/eupl-1-2
Is there any known project that actually uses the EUPL?
GoatCounter: https://github.com/arp242/goatcounter?tab=License-1-ov-file
Thats a modified version, see further up in the thread.
There's a few, but not too many. See e.g. some package repos:
https://github.com/search?q=repo%3Afreebsd%2Ffreebsd-ports+%...
https://github.com/search?q=repo%3Avoid-linux%2Fvoid-package...
https://github.com/search?q=repo%3ANixOS%2Fnixpkgs+%22EUPL12...
Most of the software from the EU and some governments are also under EUPL, but those tend to be "source dumps" that no one really builds.
If you develop hardware also have a look at the "CERN Open Hardware Licence"
If you're doing open-source hardware and want to ensure improvements stay open
Yes. All my OS projects have a strong Copyleft-clause.
Cannot stand companies stealing stuff and giving nothing back.
Thanks god they hate Copyleft licenses like the plaque.
Need more copyleft for freedom
What additional freedoms do you want this licence to provide?
[dead]
[flagged]
Once again, the EU coming 30 years later to do something everyone else is doing, and everyone will credit them for some odd reason.
In the 90s, there were dozens (hundreds?) of phone charging ports. A couple of years ago, there were only two. The dozens -> 2 simplifications occurred on the purely free market. And the EU mandated a simplification from 2 -> 1 and gets the credit for the entire simplification.
What is the point of this license? Either the GPL is invalid in the EU, in which case why aren't companies moving to the EU to infringe on the GPL? Or it is valid, in which case a a bunch of EU lawyers were given a bunch of MY money to do nothing of value to anyone.
Whenever something from the EU emerges on HN, whatever that is, a comment exactly like yours is made.
Today it's you, tomorrow someone else.
Always the same "points" and the poster always seems to feel obliged to bring their own misshapen view of history, forgetting that a lot of good changes in this so-called "free market" happened because of the EU.
Sure more tech became popular out of the US but let's not be blinded:
1. This tech isn't/wasn't the only innovative tech ever created
2. A lot of reasons for the popularity has to do with US position over the rest of the world
3. That this same tech has been kept at bay because of the US
I'm not saying the EU is perfect but I prefer its direction over the US, especially when it comes to making legislations which benefits the people rather than multinational corporations.
I simply do not think that the popularity of US tech is due to anything other than the quality of US tech.
I live in Romania, and the people that were rushing to pirate Windows in the 90's after communism fell because they couldn't afford licensing weren't doing so because of any US imposition, but simply because they wanted to use personal computers, and Windows was the best OS for most people at the time for that purpose.
Just like when phones came around they rushed to buy Nokia phones; when smartphones came around they rushed to buy Samsung phones; when they wanted DLSRs they bought Canon and Nikon cameras and now that they want easily transferable digital cash and cheap tech trinkets they opened up Revolut accounts and order stuff off Temu.
Not because of any "influence" or "position" of Finland, South Korea, Japan, the UK or China, but simply because they are the best offer on the market as perceived by consumers.
What tech does Europe lead in? To be fair there are still some fields, like Aerospace (Airbus), Lithography (ASML) or Pharmaceutics (BioNTech). But on the consumer tech market, the phones, laptops and streaming services people want? The EU has no presence. Even the auto industry is going to be eaten up by China, because Europe simply pivoted too late to EVs. I know someone who works at Renault and they're just terrified of the cars that are coming out of China.
I see your point but that stops being true once the bigger companies start stifling competition (both locally and internationally) to become even bigger and more pervasive.
There are European alternatives for many products/services that are currently US-based but they either don't have the same marketing budgets, or international reach or can offer lower prices. All those are often due to first-to-market tied with anti-competitive practices (further tied to governments not having much power against these organisations) which makes these companies move even more to the top. None of that was about better tech but rather everything else.
And sometimes yes, better tech, but let's not fool ourselves into thinking that "better tech" is not somehow tied to more money available to spend on improving such tech. Big capitals being moved around the US has an impact to this tech.
By the way, there are European alternatives Amazon (just not big enough to be international, but many countries have their own version), Microsoft (i.e. Linux), Google (ProtonMail/ProtonDrive , Nextcloud, etc.), AWS (the ones which comes to mind are Upcloud and Hetzner), Android/iOS (Ubuntu Touch)
> quality of
More like ability to buy competition.
> But on the consumer tech market, the phones, laptops and streaming services people want? The EU has no presence.
I'm working on it, give me another ten years <3
> The dozens -> 2 simplifications occurred on the purely free market.
That was also done by the European Commission[0].
[0] https://en.m.wikipedia.org/wiki/Common_external_power_supply
That was not done by the European Commission. It was a document with no legal power. And it was an acknowledgment of an existing market trend. non-iPhones had already began converging on USB charging (including mini-USB and micro-USB) in the years before.
By the time the EU actually first proposed regulation on the matter, which was only in 2020, there were in effect three ports on the phone market: the Apple Lightning was still used in iPhones, and the rest of the market was undergoing an orderly migration from the cheaper micro-USB port, to the more expensive but better USB-C port.
So yes, the free market was entirely responsible for transitioning from dozens of ports to 3 ports, and would have very likely eventually transitioned to 2 ports. The fact that the EU made recommendation to that effect years ago after the trend had begun that was purely voluntary is an entirely irrelevant datum.
That's not really what happened. The European Commission made gave the manufacturers a choice: they could sit down and come up with standard that they voluntarily accepted to follow or the EC could write the standard and force the manufacturers to follow it [1].
I imagine they would have eventually converged on USB anyway, but when the upcoming rules (or "rules") were announced, you definitely could not count on being able to charge your phone using anyone else's charger (or one of the many that had come with your previous phones).
Counterfactuals are tricky, and we'll never know for sure what might have been, but seeing laptop manufacturers dragging their feet, I really can't see how you could feel so certain that the market would have fixed the mess that existed just as quickly.
[1] https://ec.europa.eu/commission/presscorner/detail/en/memo_1... (search for "ultimatum"
This is how good legislation works.
Good legislators let it be known that a situation is unacceptable and that legislation is coming.
Good companies respond to that and start to align with the legislation.
When the legislation becomes law - no one is shocked or surprised or caught out.
I don't think you actually know the history.
EUPL almost 19 years old (first published in Jan 2007).
... Eh? It's from 2007. Licenses like this weren't at all common at the time; there was the original Affero license, but AGPLv3, the first version to see widespread use, didn't come out until later.