Live data from Hacker News

Commons Clause

redislabs.com

181–190 of 496 posts

Re: Commons Clause

#181

>Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed. Then it seems the solution is simple: use GPL rather than BSD. In other words, say "Do you want to use this free software for your benefit? Fine, but in turn give bac…

I don't see how the GPL helps. AWS etc make money by providing Redis as a service, which the GPL allows. If most of the work they have done is to support Redis, rather than changing code in Redis, nothing changes.

Re: Commons Clause

#182
post #61

For the record, this license is obviously incompatible with the Debian Free Software Guidelines; I suspect it is non-free enough to not even be shipped by Red Hat and the other semi-commercial *nix's.

Curious about vendors like Red Hat as well. Seems like their umbrella support would conflict. Also curious about companies that might want to bundle Redis in their product

It'd need to be clearly marked — the promise we make in Debian ``main`` is quite strong: if you install it, you can use it for any purpose, modify it, share the changes with your neighbour, etc.

And (although not explicitly codified, we touch on it in "must not contaminate"), you can install Debian on a system, install any package in ``main``, then clone the resulting disk and redistribute it as an image. This precludes having things like ``zfs`` in ``main``, as (last time I reviewed it), it was pretty clear that the resulting combined work was probably not redistributable.

(N.B.: I'm on the team that maintains ftp-master.debian.org, and reviews all new software for DFSG-freeness, amongst other qualities)

Re: Commons Clause

#183
Are the four popovers I had to click through to get to the article really necesary?

- Notice about updated privacy policy

- GDPR opt-out (where the ‘No’ button is hidden on the next screen)

- Chat system

- Banner ad for an event

Re: Commons Clause

#185

Earlier quoted context omitted.

> Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis. True! But that means today's Redis is in maintenance mode, with all new commercially-relevant features covered under the new license.

True, but that assumes that Redis is the only one capable of coming up with commercially relevant features. If the community fork of Redis gets commercially relevant features, then Redis will have to do work to re-implement them. Moreover, that assumes that said commercially relevant features are compelling enough for people to upgrade from the unencumbered version of redis that they have to the encumbered version.

This seems like a superior alternative than allowing cloud providers the ability to generate revenue with your product that you receive no portion of. If you're already substantially "losing", there is no harm in doubling down. RedisLabs has nothing to lose by doing this other than people moving to another solution that someone else will need to expend resources and time to develop.

Monetization shouldn't be a four letter word. People need to pay their rent and eat.

Re: Commons Clause

#186

Earlier quoted context omitted.

The difference is the second company is earning money directly off the labour of open source software ... that and the fact that the second company is worth billions. None of this would have happened if AWS etc had of supported the open source contributors and projects that they were relying upon in some meaningful way. I actually support this move and wish RedisLabs the best of luck.

What if the first company is also worth billions and hasn't contributed anything upstream? How is that any different?

The revenue component is still different. In the first case, they are saving the cost of purchasing equivalent software. In the second, they are earning money. It's a subtle but important difference.

Re: Commons Clause

#187

Earlier quoted context omitted.

> It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks. Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years,…

> Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product? The consultant isn't selling the product; they're selling a complement to the product: knowledge of how to use the product effectively in the client's circumstances. But complemen…

[deleted]

Re: Commons Clause

#188
post #114

Earlier quoted context omitted.

The FAQ at https://commonsclause.com says it was drafted by Heather Meeker.

(the FAQ was added after I posted) That's worse because Heather would have certainly warned them of these issues, and it means they did it anyway.

I'm guessing she's a well-known practitioner in this field. Why would one be involved in such a thing, given it's so problematic? The whole thing seems super-confusing and half-baked.

Re: Commons Clause

#189

> However, today’s cloud providers have repeatedly violated this ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. Well, if that's the way you see it, then sure, go ahead and limit the software's use. But there are a lot of people, like myself on my OSS stuff, that do not feel like they're being taken advantage of when their software is…

Looking at Redis [Labs], their livelihood is based solely on consulting and revenue generated from deploying Redis. Cloud providers are clearly netting multiple millions and not passing that upstream in the form of consulting, project donations, etc. This is one workaround. It works.

> This is one workaround.

And a poor, misleading one. While solutions exist.

> It works.

That's to be seen. While actual solutions already work.

A solution would be a proprietary license. Neutering the Apache 2 license while still calling it Apache 2 does a poor job of both properly licensing it or clearly advising potential users what their rights would be. In fact, calling it 'Apache 2 with modifications' is about as correct and honest as calling a dead man a 'human with injuries'.

Re: Commons Clause

#190

Earlier quoted context omitted.

> "including without limitation fees for hosting or consulting/ support services related to the Software" This single line completely destroys any confidence I have in Commons Clause. I will avoid any project with this license moving forward until this is fixed. It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the ina…

> It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks. Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years,…

Redis core is almost exclusively written by Salvatore. Redis Labs itself was just a consultancy that monetized this work and eventually hired him on full-time many years later.

So if this license had existed from the beginning, Redis Labs wouldn't exist. See the problem?

Post reply on HN