Hacker News new | ask | show | jobs
by palata 842 days ago
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?
2 comments

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.

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.