Live data from Hacker News

Commons Clause

redislabs.com

131–140 of 496 posts

Re: Commons Clause

#131

Earlier quoted context omitted.

Zealots have stolen every commonly used term for open-source software. There's no reason we need to respect the artifice constructed post-facto by groups like the OSI. "Open-source" can and should be used in its common sense. Raymond et al missed a big opportunity to create a more commercial-friendly open-source license by deciding to organize around a philosophy so similar to the one promoted by the FSF. The insiste…

There's no reason we need to respect the artifice constructed post-facto by groups like the OSI. "Open-source" can and should be used in its common sense. The OSI definition is the "common sense" of Open Source and has been for at least 20 years.

No, the number of sanctimonious lectures that occur every day about how someone is using the term "open-source" incorrectly clearly indicates that the OSI's definition is not common sense. The plain meaning of "open-source" is just what it says: the source code is open, i.e., not closed, i.e., accessible to users. Let the OSI and other zealots harp all they want, this type of subversive hijacking is not cool.

Re: Commons Clause

#132

Earlier quoted context omitted.

>substantially Wow, that's a legal landmine. Is there even a legal standard or consensus for what "substantial" means?

It's something that would be decided by a judge or a jury.

Right, exactly. So at this point how am I supposed to use your software for anything commercial at all, without the fear that one day you'll decide it's offering me substantial value? (If the answer is "Do not" then just license it correctly).

Re: Commons Clause

#133
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'…

> Any license notice or attribution required by the License must also include this Commons Cause License Condition notice.

FYI, think you have a typo, shouldn't it be "Common Clause" not "Common Cause".

Re: Commons Clause

#134
post #104

Earlier quoted context omitted.

I agree that we need a good open-source license that limits the ability to resell. The paid support model only goes so far. If a clause like this is actually successful, we may start seeing companies that sell software (rather than support) looking to avail themselves of the benefits of open-source, which would really be a boon for everyone. Someday, I'd like to see a mandatory source deposit to get copyright protect…

Like it or not, "open source software" already has a well established meaning. If your license includes restrictions on use then you need to call it by an accepted name for that kind of license, e.g. "source available" or "shared source". Anything else is simply deception.

No, you only "need" to do this if you're interested in furthering the claims of license zealots, who are more interested in furthering their personal political goals than they are in allowing computer users to get access to the source code that produced a binary blob. Making "open-source" synonymous with "freeware" is a massive poison pill that has hurt the industry substantially.

Re: Commons Clause

#135

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

Re: Commons Clause

#136

The problem this license is trying to solve is a reasonable one: that cloud providers package up open source products as their own service and capture the majority of the value without adding much themselves. This license might not be the best way around it but the issue should be addressed.

Agreed, most of the Revenue from OSS is from hosting it, not developing it. As a result the biggest cloud vendors make most of the profit from OSS that others have developed and spend resources on maintaining.

Not sure what the solution is either, but the major cloud companies are becoming an oligopoly who rake in most of profits in OSS giving them a competitive advantage which they can use to out resource, out market and out compete against alternative Indie OSS efforts.

Whilst the desired effect would be that the Cloud companies would pay Redis Labs a cut of their profits they make on Redis, IMO they're already big enough that they can invest more development hours in developing a superior competing replacement which they can use as a competitive differentiator vs other Redis hosts. But hopefully they'll consider profit sharing instead of developing a proprietary cloud-only fork.

Re: Commons Clause

#137

> 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. It works.

A bit early to tell I'd say. Always hard to know who doesn't use something because of these things. But I think everyone can agree that this wouldn't have worked from the start; needed to build up a dependence on the software and interfaces before springing this. Feels a bit bait-and-switch every time someone's software gets commercially popular so they feel the need to change tack. Almost makes me wish it didn't become popular and widely distributed so the developers don't get this urge to do the switch. Then again, I'm always happy to see people get rich when they work hard on stuff.

Re: Commons Clause

#138

Earlier quoted context omitted.

If they're concerned about brand dilution via resale of "Redis"-as-a-Service RedisLabs could easily trademark the term Redis and prohibit its use in this way. This mechanism is much the same way Mozilla controls the Firefox trademarks. I do wish they hadn't made their Open Source licence a confusing mess and effectively proprietary for certain modules. That's their right, of course - as copyright holders. However, it…

I mean.. I'm sure they're concerned far more about corporations making money off their unpaid work by hiding it under many layers of abstraction. "Use our stuff for free to do new stuff. But if you're making money off our stuff by selling our stuff's features, then we need to talk licensing first." If this is an accurate summary, I really don't see anything scandalous about it.

Surely this kind of resale of enterprise proprietary software modules is already prohibited by their enterprise licensing scheme. If it's open source, this is precisely what open source is meant to do. It's supposed to be a means to an end to enable new functionality - the fact that it's being sold doesn't matter. The key is that we all gain that ability. If they want to compete in that space with their open source product then they should run a hosting outfit - not try to rent seek from people adding value by actually running their code in production.

Re: Commons Clause

#139
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'…

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…

What efforts has your organization made to prevent software companies from selling "Hosted [open source project] as a Service (with a proprietary twist)" offerings while not contributing back to the OSS core project's development?

Edit: Or rather, incentivized contributions, or disincentivized a lack of contribution

Re: Commons Clause

#140
Weird thing is it just a few months ago that AWS contributed what I would consider a pretty significant feature to Redis - encryption in transit:

https://aws.amazon.com/blogs/opensource/open-sourcing-encryp...

While it’s not merged yet, antirez at the time seemed pretty onboard with the approach. ( first Point in https://news.ycombinator.com/item?id=16943289 ). The delay in merging seems understandable based on the comments and discussion on the PR.

So leaves me wondering what’s changed. Obviously antirez != redislabs and their focus is on the OSS side of redis, but the announcement seems to suggest that none of the cloud providers contribute back which isn’t the case?

Post reply on HN