Hacker News Reader

Comment by drewdevault | Hacker News Reader

LGPL is a pretty weak copyleft license and was chosen specifically because it is amenable to almost all present-day commercial use-cases for Redis. You don't have to publish your changes to Redict in most situations, commercial or not. Check out the FAQ here:

https://redict.io/docs/license/

View on HN

"Tip: Commercial and non-commercial users of Redict are not required to publish or otherwise “open source” the source code of Redict, including any private modifications they make to the source code"

And very next section:

"If you compile Redict’s source code into an executable form and distribute this executable form to others you are required to include a copy of the Redict source code and any modifications to it licensed under the LGPL."

Let's be real: Especially in the EU, the definition of distribution of derivative works is typically so strong that it's super risky to use any copyleft license and I personally (e.g. consulting for large companies) see huge issues with compliance whenever this happens.

In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.

Note the careful use of private modifications as not requiring disclosure of the source code. You only have to include source in the very specific situation of building Redict and providing it in compiled form to customers directly. Like, if you give someone the ELF file. If you run it on their behalf as a cloud service or something you have no obligation to provide source, which is the most common commercial use-case of Redis.

LGPL is a very well understood license, even in the EU, and is already in use for many projects that are widely depended on commercially. Consider ffmpeg as one prominent example, which is used by virtually all multimedia software in the industry. It is very easy to comply with the LGPL, and your legal department works for you, not the other way around.

> legal department works for you, not the other way around.

Not sure what planet you live on. Unless you are one of the execs, Legal (and other compliance departments like HR) work pretty much against you. They exist to protect the company and the exec team.

They exist to serve the bottom line, and if the bottom line is best served by evaluating and approving the LGPL license (a trivial task, as it is broadly understood and the compliance requirements are negligible for most users), then that's what they will do. And in any case, no one is categorically opposed to the LGPL. Unless you think that no one is using Linux in industry, given that it uses a stronger license (GPL), which is patently absurd.

> And in any case, no one is categorically opposed to the LGPL.

That's not exactly true, take android as an example, which has a policy of "no GPL in user space", if I recall correctly.

I do however believe that due to drivers and other things, GPL is beneficial in Linux kernel, but that rather an exception. And also Linux is GPLv2, which is a big difference to GPLv3 (and so to LGPLv3).

In my experience, legal is perfectly supportive assuming you're sane, reasonable and not a dick to them. They have expertise and constraints (ie: client contracts, bandwidth, etc.) that you are not aware of but that's different than being your enemy. If your attitude to them is that they're your enemy then they will be your enemy because why would they treat someone who is clearly antagonistic to them as a friend?

Legal may sometimes be stubborn dicks, they can be overly conservative and afraid, but basically they are there to protect you from doing stuff that would create problems for the company and usually lead to you being fired or even being arrested in consequence. And they are working from the context of potentially fighting against a hostile legal challenge from people like them working for other companies, agencies, the law or the government. Yeah, they know that we are talking is just common-sense, but the law machinery not always work according to common-sense, and they know it far better than you.

Be cooperative with them, and they will usually try to help you. And don't try to teach them their work, after all, they don't try to teach you how to architect and code.

> Especially in the EU, the definition of distribution of derivative works is typically so strong

Maybe I'm naive but how strong can it be? And is there anything that can't be solved by liberally decorating your software with links to the git repo of Redict?

That is absurd. LGPL is widely understood. Compliance is generally pretty easy. The Linux kernel has many users, and it is GPL.

> In other words, it doesn't even matter what the current intention of using this license is regarding commercial use (but not distribution?)... I would not recommend to use this commercially for multiple reasons including risk, career but also the fights to be had with legal compliance.

In a non-technical firm with no relevant expertise outside the software devs, maybe. But in every software company I've worked for, legal has been more concerned with the AGPL, or Oracle's proprietary licenses, than LGPL which has always been explicitly approved.

It's a massive stretch to read "distributing the executable to people" as "distributing derivative works by somehow using this service in your network". The language is very clear.

What would you consider a website?

Is minimized JavaScript considered an executable?

What about html and css?

How would you compile Redict's source code into a website? And if you somehow did, it would be an executable, yes.

I've had to go over open source package licenses as part of due diligence when my startups were acquired, but LGPL was never an issue, unlike AGPL.

Reply on news.ycombinator.com