Ask HN: What do you think about EUPL in comparison to other copyleft licences? | Hacker News Reader

Ask HN: What do you think about EUPL in comparison to other copyleft licences?

4 pointsmarc13617 comments

How do people here think about the EUPL, especially when compared to licenses like GPL, LGPL, AGPL, MPL,...?

https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

I saw e.g. https://news.ycombinator.com/item?id=37160740 and https://news.ycombinator.com/item?id=14053129 but they don't contain discussions.

I like that:

1. I can read it in my native legalese and not just the English one.

2. That it is fully translated into 23 languages (and not in a "this-is-not-the-real-legal-text" way), but each is binding.

3. That it was created for the jurisdiction where I live, and not just for the US judicial system.

4. That linking to my program does not force the other program to use my licence, but using my code enforces that product to use a copyleft licence. Real explanation on https://joinup.ec.europa.eu/collection/eupl/news/understanding-eupl-v12

Are there key things that I'm missing? Are there other problems than the ones nodemailer had?

Would love to hear some opinions.

You could add: - the EUPL, like the AGPL, covers all distribution modes (remote or SaaS...) - the EUPL includes a CDO (contributor declaration of origin) - the EUPL specifies more "realistic" liability exclusions (at a time the CRA Cyber Resilience Act is discussed it is better to face some potential issues: total liability exclusions, like in the MIT license are simply invalid). - the EUPL is compatible with other "copyleft" licenses because it allows combined derivatives to be distributed under these (without giving up fundamental obligations of sharing and reciprocity, as none of the compatible licenses is in conflict withe the EUPL on these points. - the EUPL is not "born in the USA" but is definitely not an "obscure" license. The upcoming Interoperable Europe Act states that all EU interconnected open source portals shall propose it (this is not exclusive of other licenses of course, i.e. if the GPL or AGPL is inherited). - the EUPL philosophy was recently explained in a paper "The seven pillars of Wisdom": (https://joinup.ec.europa.eu/sites/default/files/discussion/a...) This is just a discussion paper. You are welcome!!!

Nodemailer author here. I now publish all my libraries/tools (like Nodemailer) under some permissive license (MIT, MIT-0, ISC). This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway. For example if I build a OSS software and commercial software that both use such library, then it is easier to manage it under permissive license - I don't want copyleft licenses turning up in my commercial software even if I'm the owner.

For OSS applications, I use EUPL (eg. https://wildduck.email/) or AGPL copyleft licenses. The license does not stop anyone using it as an application, but at the same time people are not free to copy, rename and sell it either.

> This gives the opportunity to use such a library without issues, and the end user never knows about these tools anyway.

Why not something like MPLv2 then? It does give the opportunity to use the library without issues, the only constraint (compared to e.g. MIT) being that changes to the library needs to be distributed. If you don't change it, then it's pretty much like MIT.

To me, MPLv2 is superior to MIT in the sense that it gives developers leverage against their management. If I tell my manager "I fixed a bug in this MIT library, can I contribute it upstream?", the answer is often "let's discuss that later" or "hmm we'll have to see with legal" or "are you sure that it is not a competitive advantage for us?". In my experience, managers never see value in contributing anything back.

Now if the library is MPLv2, I can use it just like MIT, but if I fix a bug I can tell my manager: "it is MPLv2, which means that I must distribute my changes. Are you fine with me contributing them upstream?". Again in my experience, the manager will just say "if you have to, then do it". Even though (AFAIU) MPLv2 does not enforce contributing upstream: you just have to distribute the changes with the software (to your customers). But managers generally don't know anything about licenses, so "contributing upstream" is a good-enough approximation.

TL;DR: with MPLv2, the developer has leverage to bring their changes upstream. With MIT, the manager can happily keep the changes proprietary. I am a developer, I want to open source my code. Therefore I want copyleft.

You are right: MPLv2 does not enforce contributing upstream. So you turn your manager into a fool (just a little bit). The MPL is probably one of the best F/OSS licenses: clear, concise, well written... But this is - hopefully - true for the EUPL as well.

There are two meaningful difference between licenses.

One is the size of the pile of money you are willing to pay lawyers to enforce it. Because there is no software license enforcement agency that is going to sue neerdowells on your behalf.

The other is excluding good actors who don't want to deal with it. Obscure licenses increase the number of good actors who will forego using the software because parsing non-standard licenses is work and raises questions about the competence and/or motives of the developer.

Obscure licenses don't protect users. Good luck.

If I understand you correctly, your advice is that EUPL is an unknown/obscure license and you would not choose it for that reason?

Thanks for the good luck wishes, but I don't intend to throw money towards enforcing the license at all. I mostly don't want to be liable for code that I open source.

And restricting it to EU would solve the problem that e.g. WTFPL or UNLICENSE have with countries that don't acknowledge public domain.

This is more a question out of curiosity for me, and many people react allergic to viral licenses, GNU or RMS so I was looking for alternatives because I also heard there were issues with CC-share-alike.

I would not choose it for two reasons:

1. The bad actor case: On my side of the equation there is no practical difference between licenses. Enforcing one or the other has the same legal costs…either I lawyer up and enforce whatever license I used or I don’t.

2. The good actor case: When users are unfamiliar with a license they are less likely to use it (or in a business context less likely to be allowed to use it).

By the way, CC-0 is an alternative to the public domain.

> 2. The good actor case: When users are unfamiliar with a license they are less likely to use it (or in a business context less likely to be allowed to use it).

Businesses typically don't want copyleft because they don't want to share anything (even if that is counter-productive). If more codebases used copyleft, I'm convinced that more businesses would know how to deal with it.

My second thought here is that I don't like this "people won't use is" blackmail. I write software that I share for free, I am entitled to choose under which conditions you can use it. If you can't be arsed to spend the time needed to understand my conditions (and the EUPL is not exactly a 200-pages long license), then don't use it. It's not like you were going to pay me anyway, right?

I am telling you why I wouldn't use an obscure license if I wanted to share my work.

When I don't want to share my work, I simply keep my work to myself.

You are indeed free to choose whatever license you want.

I have zero issues with that.

Sorry, I didn't want to sound aggressive at all :-). Of course that's your choice. I was just sharing my preference.

In my experience, many developers tend to prefer the licenses that are better for their company. And I don't get that. They should prefer the licenses that are better for themselves. If my company is forced to use a GPL library because there is no alternative, then I get to open source my code. That's great for me personally! Conversely, if I get to publish code I wrote in my company, if I manage to do it under a copyleft license, it helps other developers open source their code.

I understand that GPL/LGPL maybe scary in some situations (how do you deal with LGPL in a proprietary iOS app?), but I haven't found a single example where MPLv2 doesn't work. I don't see a reason to use a permissive license, MPLv2 is always fine.

As a developer, it's never good for me to help a company get permissive code for free.

Can't we reasonably assume that an official European license is not exactly "obscure"?

I had never heard about it, but it seems nice! Am I right that it is really about "sharing" the code and not so much about "allowing to modify", in the sense that it does not prevent tivoization? Or did I miss that part?

I'm not sure if I understand correctly.

For me, it is mostly about "sharing the code" as in: I put it somewhere and anyone who wants can use it. But if they adapt or remix it, they should also use a free license (ideally contribute back to my project).

> in the sense that it does not prevent tivoization?

I'm not sure, but I guess it does not protect against tivoization because if I were to distribute an executable or library, that could be used on a blackbox with proprietary code without them requiring to open their own code.

> For me, it is mostly about "sharing the code" as in

Sure, I did not express it correctly. I really just wondered about the tivoization.

> But if they adapt or remix it, they should also use a free license

I think that the code has to stay EUPL, but if you merge it into, say, a bigger GPL project, then the whole project can count as GPL. But the EUPL code inside stays EUPL, right?

You are right, there is a "double coverage". The EUPL just states that the compatible license (applied to the combined derivative work) will prevail in case it conflicts with the EUPL. But none of the listed compatible licenses (i.e. GPL-v2 or GPL-v3) prohibit, for example, the coverage of remote/SaaS distribution: they may not impose it (SaaS loophole) but allow it. So the EUPL code inside the combined derivative will stay covered by essential EUPL obligations, including the modified code sharing in case of remote distribution, even when the combined work is globally distributed under the GPL.

For me - correct me if I'm wrong, the tivoization issue looks mostly related to what is really a "derivative" of your work (i. e. in case the level of dependency of some hardware device that uses/incoprporate your software is so high that it can be considered as a derivative). For this reason the EUPL-1.2 covers "the Work", that could be software code, ancillary data, documentation, or even hardware in so far it could be considered as a derivative.

Hmm not sure. Tivoization is about distributing a product together with the source code running on it, but without giving a mean to update the software.

That's the difference between GPLv2 and GPLv3: if you buy an Android smartphone, you are entitled to receive the Linux source code for that smartphone. But maybe there is a secure boot and it is impossible for you to flash an updated version of Linux.

GPLv3 says that not only you should receive the source code, but also instructions about how to flash your own version of the covered software.

It feels like EUPL is closer to GPLv2 in that sense, right? Which is fine, but it's good to know.

Reply on news.ycombinator.com