Hacker News Reader

Comment by zwaps | Hacker News Reader

If you have a commercial use-case, there is also a non copyleft fork available here

https://www.linuxfoundation.org/press/linux-foundation-launc...

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/

"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.

Most commercial projects can safely use any of the Redis forks, whether Redis itself, Redict or Valkey. For Redict, you have to provide the source code of Redict - and Redict only! - in the case that you distribute it to customers. Redis has harsher terms, but only if you provide Redis-as-a-service. If you aren't a cloud provider and you don't modify the code of your chosen Redis variant, this is all a big nothingburger and neither of the licenses impose any important restrictions on you.

We desperately need all open questions regarding AGPL and SSPL to be clarified in court so this fearmongering can stop. It's really really bad for open source.

> If you aren't a cloud provider and you don't modify the code of your chosen Redis variant,

Or get hosted redis services from someone other than Redis Labs. That isn't fearmongering about the SSPL, it is literally the point of the SSPL.

Sure, but that's left for the hosted service providers to figure out. No one can sue you for using AWSs offering.

Open source seems to be doing fine without the clarity. Even fields that have nothing to do with software are adopting the mindset. The movement only gains in steam

Most popular OSS projects use Apache and MIT in my experience, precisely because GPLs are problematic for commercial usage and contributions from employed people.

This is a common misconception and source of fear/uncertainty/doubt regarding copyleft licenses. It's true that, the stronger the copyleft license, the more obligations it imposes on companies, and the AGPL is perhaps the most onerous of all and thus the least attractive to businesses. But, copyleft exists on a spectrum, and there are thousands of big-ticket FOSS projects that tens of thousands of businesses depend on and make use of that have a copyleft license. Linux itself is GPL, and pretty much everyone depends on it.

The license for Redict is one of the weaker copyleft licenses and should not pose any onerous compliance obligations on the most common commercial use-cases for Redict.

That has been a popular opinion since FreeBSD was a complete operating system and Linux and bunch of disparate tarballs. Yet here we are.

There have been other examples where copyleft products have competed with more permissively licensed products as commercial products. The results are overwhelmingly in favor of the former.

Empirically, cooperation works much better on a level playing field where your company's work won't be included in a competitors closed fork.

Don't know why this is downvoted, I have endlessly heard corp lawyers say this to my face while I worked there.

I have had a "popular" open source library I contributed significantly to campaigned by Microsoft to change the license to MIT, and the founder and creator decided to relicense without getting any sign offs because they felt that nobody would get mad enough to sue them.

The only thing stopping a commercial product from using copyleft software is themselves, not the copyleft.

Lawyers entire job is to make convincing arguments for any position you want, by artfully speaking only true facts, no matter what the position is and no matter what the facts are.

Of course a lawyer can and will say that you "can't" let any gpl software pollute the companys product "because the gpl prevents it", instead of saying that the company doesn't want to pay the license fee for the software.

The facts of the gpls terms may be true, and the lawyer may present them for their argument, but that still doesn't make the overall assertion true.

They can use gpl software all they want. They just don't want to. And good for them. That is better than simply stealing it which many do.

It's also merely an assertion that "most" open source software uses apache/mit/bsd wthout some numbers and citation. But that sentence could be parsed more than one way. They might have only been saying that most of the projects that use apache/mit do so for commercial compatibility reasons.

Corp lawyers job is to derisk and protect the company.

Strong copyleft risks converting private IP into something that must be shared publicly. This is what these licenses are designed to do. Blanket bans on specific licenses makes sense because they don't have the time to evaluate every potential case or usage

How many of the copyleft projects actually have a commercial offering or paid support plan?

Who said anything about a commercial or paid support plan?

The price the corp doesn't want to pay isn't money.

There are no potential edge cases to worry about if you aren't trying to live on renting copies of the same software to many people in the first place. Then you can live it even greater safety with no need to even audit anything.

Reply on news.ycombinator.com