Hacker News Reader

Hacker News

Comment by Santosh83 | Hacker News Reader

Full thread

Santosh83

> Clojure's license makes it a complete non starter for me, sorry. Live free or die.

Can someone ELI5 this? Why is Clojure's license problematic?

View on HN

Not GPL-compatible:

https://www.reddit.com/r/lisp/comments/hupqhn/the_many_faces...

I am by no means an expert on things to do with licensing but Clojure is under Eclipse so IIRC if you distribute your code onto the user's machine they have a right to the source.

This can make on-prem solutions for a product slightly hairy.

Please feel free to correct me if this is inaccurate

> This can make on-prem solutions for a product slightly hairy.

EPL has the restriction that if you distribute binaries, you have to make the source available (you must state in your license where to obtain it). It seems that listing your dependencies libraries and linking to their websites (which I think is good practice anyway even with less restrictive licenses) would be enough, as long as you didn’t modify them.

EPL allows linked modules to be distributed under whatever license you want, so in a commercial product doesn’t apply to your closed source code or any libraries that choose not to be distributed under EPL.

So for on prem distribution, you just need to include a license file that lists all of your EPL (or other licenses that require the license to be included like MIT) with a link to where to get the code. Your own code is unaffected.

This isn’t GPL compatible, though, because GPL does “infect” linked modules too.

However IANAL.

The problem with the EPL is that if your software is a derivative work of EPL licensed software, the EPL applies your software, including the obligation to provide access to the source of your software to the entities to which it is distributed. Determining if a work is a derivative work in software is far from straightforward. The EPL FAQ for instance points out that this might be an issue when using software that generates code.

This is the reason why the Classpath exception exists for GPL. Perhaps EPL would also consider adding one?

That cannot be the problem that the author of the submitted article has with the EPL, because the GPL is the same way.

No, I agree. I was pointing out a general challenge with the EPL that people tend to overlook. In the Clojure environment many use EPL for Clojure libraries, many without realising that it might, depending on your intentions, be an issue.

> This isn’t GPL compatible, though, because GPL does “infect” linked modules too.

I don't think that's the reason. The BSD license is GPL compatible, without infecting anything.

EPL being GPL incompatible means that EPL-licensed pieces cannot be combined with GPL ones for whatever reason. The FSF claims that it is because of its "weak copyleft and choice of law clause".

https://www.gnu.org/licenses/license-list.html#EPL

Given the amount of surviving GPL software that still has some meaning, basically Linux kernel and GCC are the ones left, that reasoning won't hold for long.

Actually, that's a good point I hadn't thought of. The world has moved on from GPL to more free alternatives.

I wouldn't call the missing upstream improvements to LLVM and BSD from Sony, or Apple, thanks license, a more free alternative, but I digress.

More free in the sense that you, the person making a derivative work or distributing the licensed software, have more freedom in what you can do. It’s not more free to your users unless you decide to license it to them under a similar license.

The original authors not receiving your changes doesn’t seem to me to affect their freedom, even if it kinda sucks.

I think the kind of licensing you’re referring to is usually called permissive licensing [1]

[1] https://en.wikipedia.org/wiki/Permissive_software_license

I am merely stating that less restrictions = more freedom (ie more choices of what you can do) to the initial user. I'm also pointing out that this freedom of choices does not translate to downstream users since the previous user is free to choose to restrict it. GPL has less freedom (by virtue of adding restrictions on what can be done), but it does this to make sure all users have equal freedom. Some people value the higher freedom more, other people value the equality more.

Separately, I was pointing out that contributing back upstream is a beneficial and nice thing to do, but is orthogonal to freedom. If anything, forcing it means there is less since the person loses the freedom to choose whether they wish to or not. I'm not judging which is better either, just pointing out the differences. Sometimes less freedom for the individual is better for the whole (to ensure equal freedom for all, or so changes are contributed back), we see it in society too: we give up personal freedom for the benefit of society as a whole.

Not that I care that much as I am mostly a commercial software user/dev, but as the world returns to the days of shareware and public domain, those that drove the carts back there will find out what "freedom" means.

Had Linux nor GCC happened, and we would all still being enjoying commercial UNIXes.

I'm not arguing against GPL and friends, I'm simply pointing out that less restriction = more freedom for the initial user in the sense that they have freedom to do more things and that this freedom does not transfer downstream. I'm also saying that not contributing back upstream is orthogonal to freedom.

I'm not sure why this is contentious: GPL adds a restriction that, eg, MIT does not -- that you must contribute back. MIT lets you choose if you want to or not, therefore it provides you more freedom. Sure, GPL adds this restriction to ensure that all users have an equal level of freedom. I am not making a value judgement here at all, nor am I saying that MIT (or whatever) is better than GPL as different people have different preferences, priorities or opinions.

That restriction is why people get to enjoy the Linux kernel and GCC today.

See where the MIT freedom has taken the BSDs, and what they have gotten out of it.

Again, I was only pointing out the differences in freedom, not making a judgement about which one is better... different people have different opinions on this one, after all.

MacOS is BSD after all, I dunno what to say.

macOS has parts of BSD, most of them never contributed back.

I suggest reading a bit about macOS internals and which of those parts you actually find on any BSD variant.

More free as in enhancing the privileges of the elite programmers who control the software at the expense of mere people who think they own and control their own devices.

You mean, less free alternatives.

I am all but forced by my employers to write non-GPL code - even when I'm allowed to write permissive-license open-source software.

But beyond that, circumstances also pressure me into making software I write on my own available with a permissive license, to reach wider adoption by people writing commercial code. I occasionally have pangs of conscience about doing that, and wonder whether I shouldn't have just taken the "hit" of sticking to the more worthy license.

Could you clarify what any of this has to do with freedom provided by the license itself?

Could you also clarify whether the first example is relating to company code or personal code?

Reply on news.ycombinator.com