Live data from Hacker News

Commons Clause

redislabs.com

201–210 of 496 posts

Re: Commons Clause

#202
post #7

This is the license below. I'm pretty sure this is going to be vague enough to cause problems with a ton of legal departments. They want to be the only ones hosting it and the the only ones you call in to help with it. I get where the Redis folks are coming from, but this is basically a nail in the product and guarantees a fork if they don't turn back. === 8 The Software is provided to you by the Licensor under the L…

Redis core plans to remain BSD. I honestly think this whole thread is missing this and it's incredibly crucial.

From the article:

> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.” These modules can be freely used in any application, but selling a product whose value derives, entirely or substantially, from their functionality is prohibited.

It's a nail in the coffin for maybe a few niche modules?

Re: Commons Clause

#203
post #58

Hi folks. Kevin from http://fossa.io here. I worked on bringing the Commons Clause to life ( https://commonsclause.com/ ) and led many of the project efforts here. Happy to answer questions here (or on Twitter @kevinverse). I wanted to write a blog post to set some context because the real story is a lot less salacious then "Redis just went proprietary", but here's a quick summary: 1/ No, Redis isn't proprietary. It'…

Wow, I remember seeing this when you first started it and I spoke out against it then. I should have spoken more loudly, because I assumed no sane maintainer would have taken you seriously. Software which uses this model is not open source, plain and simple. This is a disgrace on our community and I am sorely disappointed in you and in Redis. What pushes OSS devs to cease being OSS devs is an important problem to sol…

That crosses into incivility and you can't do that here, regardless of how right you are or feel you are. You surely know this. Please don't do it again.

https://news.ycombinator.com/newsguidelines.html

Re: Commons Clause

#204

Earlier quoted context omitted.

The appeal to authority is to whatever authority OSI, Debian, or FSF may have, not to legal authority. Licensing lawyers often know those definitions, or at least know of them. But they're terms of branding, terms of politics, not legal terms of art, and not strong trade or service marks. Granted, I think it's safe to say Commons Clause wouldn't meet the old definitions you mentioned, or please the people who wrote t…

The Open Source ecosystem rests on top of the OSI definition of "Open Source". Those with an interest in preserving the meaning of "Open Source" are broad, numerous and diverse; those with an interest in subverting it to confuse "open source" with "source available" are few, and destructive.

Dont think this is as cut and dry as you make it out to be. The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech. Multiple database companies with excellent products (Rethinkdb et al) have faced significant challenges commercializing software that is open source. We need credible monetization strategies for building infrastructure level open source software. I do not fully agree with the Commons clause implementation, but I understand the need for it to exist and welcome efforts in this area.

DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.

Re: Commons Clause

#205

Earlier quoted context omitted.

> As an open source lawyer, this is definitely not an open source license in any meaningful sense… TFA plainly says that it isn't, "at least not by the official definition set forth by the OSD." > I'm sure you can make up another word other than "proprietary" to call it… TFA also answers this: > "Applying the Clause to an open source project will transition the project to 'source-available'."

I was clearly replying to the claim made that this doesn't make redis proprietary. As I said, they just made up a new word for their version of proprietary. Also, the FAQ was added after I posted. Look at GitHub commits :)

But this _doesn't_ make Redis proprietary, because Redis is and will always remain BSD-licensed, THAT is what the claim you're referring to is talking about.

Re: Commons Clause

#206

Earlier quoted context omitted.

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.

AGPL would do it, since it's specifically designed for the "cloud loophole" (or whatever the FSF chooses to call it).

No, it just requires the service provider to also provide source code. The issue here is that RedisLabs wants to ensure that no service providers can use their modules and receive money. The AGPL specifically allows people to run the software for any purpose and also specifically disallows tacking on other clauses. (As does the GPL -- the only difference with the AGPL is that providing it over a network is considered "distribution" for the purposes of license compliance).

Re: Commons Clause

#207

Earlier quoted context omitted.

Do the cloud providers make significant in-house modifications to Redis?

Big or small, they would have to duly disclose and release what they built from that tool.

No they don't. Under Apache 2.0 they only have to provide source code changes if they distribute the software. If they are providing it as a service with modifications, they are allowed to do that without redistribution.

However, I don't think anyone has suggested that they are doing that -- only that they are offering a service for money that uses Redis (and the affected modules).

Re: Commons Clause

#208
> Help! Companies are exploiting my open source software for profit!

Uh, you told them they could.

> Yeah, but they're doing it without contributing back! They're just taking what I wrote and building it into a proprietary product!

You told them they could.

> But how is it fair that they can make so much money off my code and I never see a cent?

You. Told. Them. They. Could.

Time and again I see the same sense of helpless outrage from OSS devs. You owe it to yourself to understand the consequences of the license you choose, now and in the future. All the proselytising about permissive vs reciprocal licenses has only masked the important personal choices involved. Choices that you need to make honestly and carefully, or end up burned by your own expectations.

Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all? If so, your code is a gift given unconditionally, and you should choose a permissive license.

If not, the answer isn't to release it under an MIT license and then complain about it, but to pick a license that matches your intent. The GPL exists for a reason. The MPL exists for a reason. Not because the people who use reciprocal licenses hate freedom, but because their idea of freedom is based on sharing rather than giving. A gift expects nothing in return. Sharing expects that you share as well.

Any choice is a fine choice as long as it aligns with your goals. What I don't get is trying to have both and then being upset when you're rebuffed by reality. Picking a permissive license is being the chill surfer dude who lives in a van and just, like, takes life as it comes, man. Lots of people like the idea of that dude, very few people want to actually be that dude. Don't pick the BSD license because of its cool I-don't-care image. Pick it because you actually don't care, or be forced to admit publicly and embarrassingly later that you actually did all along and it was all a show.

And for the love of god, don't pick a permissive license, slap a preface on top that says "but not really tho", and act like you've found some amazing lifehack. You're just lying to yourself and everyone else; wearing open source's uniform without making open source's sacrifices.

Re: Commons Clause

#209
post #204

Earlier quoted context omitted.

The Open Source ecosystem rests on top of the OSI definition of "Open Source". Those with an interest in preserving the meaning of "Open Source" are broad, numerous and diverse; those with an interest in subverting it to confuse "open source" with "source available" are few, and destructive.

Dont think this is as cut and dry as you make it out to be. The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech. Multiple database companies with excellent products (Rethinkdb et al) have faced significant challenges commercializing software that is open source. We need credible mon…

I would very much like to see those companies succeed. But when a company forces me to choose between their survival and the survival of Open Source as an institution, my choice is made.

Re: Commons Clause

#210
post #58

Hi folks. Kevin from http://fossa.io here. I worked on bringing the Commons Clause to life ( https://commonsclause.com/ ) and led many of the project efforts here. Happy to answer questions here (or on Twitter @kevinverse). I wanted to write a blog post to set some context because the real story is a lot less salacious then "Redis just went proprietary", but here's a quick summary: 1/ No, Redis isn't proprietary. It'…

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

To be clear, this license does not (and, according to the post, never will) apply to regular Redis deployments, so from that angle at least you're clear. Currently it only applies to certain Redis modules, which need to be deployed separately anyway.

I'm also a bit unclear on whether this would prevent you from selling consulting services for products licensed under this clause that the paying customer deployed themselves or were deployed by someone other than you.

Full disclosure: Am a Redis Labs employee, although not here in any official capacity.

Post reply on HN