Live data from Hacker News

Commons Clause

redislabs.com

331–340 of 496 posts

Re: Commons Clause

#331

Earlier quoted context omitted.

I agree. There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping. Maybe it's time to reconsider in times of cloud oligopoles. Because why would you want your software become part of the lock-in strategy of a cloud provider.

It's really sad that the GPL has essentially "gone out of fashion". It's sad that developers would be driven merely by fashion rather than careful consideration. The fact that we have free software at all is largely thanks to the GNU and the GPL.

I've always wondered why GPL dual licensing isn't more popular. In particular, I've always wondered why "GPL or ask me for permission" isn't being explored more. That still allows you to be extremely permissive but you get the make the call.

Eg if I were coding a database like Redis, maybe I'd be totally cool with people freely using it in their moonshot VC-funded trike sharing site, but not with cloud providers offering it as a paid service (or, at least not without paying me some royalties).

Re: Commons Clause

#332
post #323

Earlier quoted context omitted.

git is a both domain specific programming language and library of software routines that enable version control. Curious why you don't see it this way.

It's a separate program though, so you're not repackaging, modifying or redistributing. Let's take for example TortoiseGit, should they decide to sell TortoiseGit now, they wouldn't have a problem with the GPL because they're not redistributing git. They just say, download git and our program will connect to it. Git does not become part of TortoiseGit at any point. You could replace the git client with one that has t…

Whether TortoiseGit is a derivative work of Git is ultimately a legal question. Certainly just being a separate binary doesn't automatically make it not one. "You could replace the git client with one that has the same interface and it would still work." - that's true of any library used in any program.

Re: Commons Clause

#333
post #264

Earlier quoted context omitted.

I think you are probably right. When starting the project, creators value their work very little, but value any attention given to their project very highly, thus a permissive license makes sense. Only after success hits do they regret it. Even so, if someone was seeking fame and fortune through OSS (a somewhat foolish mission, but whatever), I would still probably recommend they release their software with a permiss…

This seems similar to how young singers and musicians end up stuck in bad contracts.

And yet, being demanding from the beginning is a good way to never get that first contract.

Re: Commons Clause

#334
https://xkcd.com/927/

I am pretty happy with GPL, MIT/BSD, Apache because I have learned it. Another nice way is Creative Commons, especially because they are modular and are mostly translated and therefor applicable in most other laws.

Edit: also you can - always write your own, but people like to read the acronyms and know what they are confronted with - go the Carmack way, last gen open source.

Re: Commons Clause

#335

Earlier quoted context omitted.

If Heroku, AWS, Google, IBM, whoever make money piggybacking Salvatore's work, shouldn't Salvatore actually ALSO make money from his work? If not, what's the reason for him to continue? Elasticsearch faced the same problem, Redis too. It's unfair to the developers if cloud providers make money and not contribute or give back a portion to the OSS developers. Myself, I would never be so liberal like Salvatore had I bee…

Salvatore is an employee of Redis Labs since 2015. AFAIK he still owns Redis itself personally, which is a very good thing. That doesn't mean Redis Labs is the only Redis provider you should consider though. For instance, OpenRedis has been founded before Redis Labs (early 2011) by people who have been very involved with the community (contributed the Ruby and Lua clients, the original website...). They are a much sm…

Thanks catwell (saw in your profile you are pchapuis and I'm very appreciative for your work and contribution to Redis, from your content to your weekly newsletter and all).

I wasn't aware of OpenRedis and I agree with you that also OpenRedis should be supported. It makes sense to have diversity and all community efforts be supported to be viable and prosper for the benefit of the whole community.

Again, thanks for the link and your contributions.

Re: Commons Clause

#336

I clarified that the Redis core ( https://github.com/antirez/redis ) remains BSD, and what I think about the license switch Redis Labs is operating on certain Redis Modules. https://twitter.com/antirez/status/1032180321834467330 and the considerations thread: https://twitter.com/antirez/status/1032192721308594176

Sorry to hijack this thread, but am I understanding correctly that Disque will be AGPL? Does that mean that building a SaaS using Disque would require me to open source the code that uses Disque? Is that the reasoning why you are choosing AGPL?

Thanks for your awesome work btw.

Re: Commons Clause

#337
Slightly off-topic, but this is a reminder why it's good to only add a new dependency to your project when the benefit is more than incremental. Any and all of them are a potential liability. Did you really need Redis or would it have worked fine keeping everything in Postgres (assuming that the latter is something you couldn't do without anyway)? Did you really need Docker or would a static binary have gotten you 80% of the way? These are important questions to ask, regardless of any particular technology. I do not have an opinion on the future of Redis, but I do on choosing a stack. Related: http://boringtechnology.club

Re: Commons Clause

#338

I clarified that the Redis core ( https://github.com/antirez/redis ) remains BSD, and what I think about the license switch Redis Labs is operating on certain Redis Modules. https://twitter.com/antirez/status/1032180321834467330 and the considerations thread: https://twitter.com/antirez/status/1032192721308594176

Sorry to hijack this thread, but am I understanding correctly that Disque will be AGPL? Does that mean that building a SaaS using Disque would require me to open source the code that uses Disque? Is that the reasoning why you are choosing AGPL? Thanks for your awesome work btw.

Hello, yes indeed Disque will be AGPL and all the changes operated in order to create an SaaS related to Disque will have to be open sourced as well. The reason of the license switch is that I do no longer consider acceptable for cloud providers to take the value generated elsewhere and monetize without providing anything back. I was a big BSD supporter but it no longer works in the cloud era for system software IMHO.

Re: Commons Clause

#339

Earlier quoted context omitted.

I agree. There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping. Maybe it's time to reconsider in times of cloud oligopoles. Because why would you want your software become part of the lock-in strategy of a cloud provider.

It's really sad that the GPL has essentially "gone out of fashion". It's sad that developers would be driven merely by fashion rather than careful consideration. The fact that we have free software at all is largely thanks to the GNU and the GPL.

There's a big push by larger corporations such as Google away from GPL-like licenses towards MIT licenses. Unfortunately many smaller developers seem to follow suit even if it doesn't necessarily suit their interest as much as it does FAANG's.

Re: Commons Clause

#340
post #191

Earlier quoted context omitted.

Hi, Kevin. VM Brasseur from https://opensource.org here. It's disappointing to see FOSSA, which claims it exists to assist companies with open source management, publish and encourage use of a clause that very clearly removes projects from the pool of open source alternatives. To do so by using the word "Commons" in the title adds insult to injury and borders on wilful deception, removing software from the commons as…

> whatever problem it is that the Commons Clause is intended to address I'm pretty sure that problem is that Amazon, Google, Microsoft, and others have hosted Redis solutions, and even if they do contribute some code, they are undoubtedly making significant profit off of Redis, of which RedisLabs sees little if any. And since these companies have an oligopoly on cloud hosting, it is very difficult for RedisLabs to co…

> I know that Elastic has had similar issues

They chose a much more straightforward solution: some addons are clearly marked as commercial. No weasel words. We can debate whether the featureset of the core product vs. addons is a good one, but at least the message is clear. With this situation that redis got themselves into, the situation is much less clear.

Post reply on HN