Over the years it has been clear that we in the “open source” camp (as opposed to the “free software” camp) were wrong all along. We won the debate, and gained little for users or developers. All that our efforts did was to make it easier for big corporations build things more cheaply and for billionaires to become trillionaires.
Totally agree. Not that the ubiquity of OSS didn't have any benefits, but now is time for a change.
I wasn't aware of the EUPL, I'm interested to know how it compares to the AGPL. There is a faq.
I mostly use GPLv3 or AGPLv3, and EUPL looks like a solid alternative. Hadn't heard of it before this post, so thanks for the pointer.
The fact that EUPL has legally valid official translations to 23 languages also doesn't hurt in a world where most of software is built and used in the wider world outside of the Valley.
This part really resonates. As someone from East Asia, though, I wish the list included at least one East Asian language: Chinese, Japanese, or Korean. Understandable given it's an EU effort, but still.
Note that compared to licenses you mentioned, EUPL is mashup of LGPL and AGPL. So not a viral copyleft license like GPL. It does not consider using EUPL code as library being derivetative work. From FAQ https://interoperable-europe.ec.europa.eu/collection/eupl/faqs
The licence is reasonably (or moderately/weakly) "copyleft" meaning that copies and derivatives works must stay covered by the same licence in case they are distributed to third parties. Applied to the source code of these derivatives, the term "copyleft" itself combines reciprocity (modifications of improvements are published and shared with everybody) and "share alike licensing” (the use of the same - or very similar - license ensures the persistence of granted rights).
The definition of derivative works depends on the applicable law. If a covered work is modified, it becomes a derivative. Depending on the case, this gives rise to interpretation: 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. Since the EUPL is provided under the European law, this ensures no "viral" effect in the case of linking.
The compatibility clause of the EUPL always brings up some confusion:
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
This is what the FSF has to say about that specific clause:
However, 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.
This interpretation would also imply that e.g. the SaaS loophole that AGPL and EUPL close, can be bypassed in this way.
The EU itself does say the following:
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.
For extra spiciness, make the license headers use your national languages. Also pointing at the full license in them. Finnish for you, Polish for me, consonant soup for everyone else
reidrac | 2 hours ago
Totally agree. Not that the ubiquity of OSS didn't have any benefits, but now is time for a change.
I wasn't aware of the EUPL, I'm interested to know how it compares to the AGPL. There is a faq.
hongminhee | 3 hours ago
I mostly use GPLv3 or AGPLv3, and EUPL looks like a solid alternative. Hadn't heard of it before this post, so thanks for the pointer.
This part really resonates. As someone from East Asia, though, I wish the list included at least one East Asian language: Chinese, Japanese, or Korean. Understandable given it's an EU effort, but still.
Orva | 16 minutes ago
Note that compared to licenses you mentioned, EUPL is mashup of LGPL and AGPL. So not a viral copyleft license like GPL. It does not consider using EUPL code as library being derivetative work. From FAQ https://interoperable-europe.ec.europa.eu/collection/eupl/faqs
mhm | 2 hours ago
EUPL was previously discussed here [1] on lobste.rs.
1: https://lobste.rs/s/msjuyz/eupl_european_union_public_license
bramh | an hour ago
The compatibility clause of the EUPL always brings up some confusion:
This is what the FSF has to say about that specific clause:
https://www.gnu.org/licenses/license-list.en.html#EUPL-1.2
This interpretation would also imply that e.g. the SaaS loophole that AGPL and EUPL close, can be bypassed in this way.
The EU itself does say the following:
https://interoperable-europe.ec.europa.eu/collection/eupl/how-use-eupl
There's some more discussion about it from the EU itself (https://interoperable-europe.ec.europa.eu/collection/eupl/discussion/clarifying-eupl-compatibility-clause, https://interoperable-europe.ec.europa.eu/collection/eupl/discussion/how-does-fsf-considers-eupl) and HN (https://news.ycombinator.com/item?id=45422512)
tauonmsdz | an hour ago
Quite recently I stumbled upon this “licensing philosophy” document, where different OSS licenses are preferred for different categories of projects.
Curious to hear others’ opinions on it – it was the first I heard about the Blue Oak license, which sounds like a good enough idea to me.
kwas | an hour ago
For extra spiciness, make the license headers use your national languages. Also pointing at the full license in them. Finnish for you, Polish for me, consonant soup for everyone else