Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Commons Clause

redislabs.com

Post reply on HN
Print view View original

121–130 of 496 posts

Re: Commons Clause

#121

Post by kemitchell »

DannyBee wrote: post #62
XiZhao wrote: 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'…

As an open source lawyer, this is definitely not an open source license in any meaningful sense (it meets no definition of open source/free software/DFSG/you name it). No restrictions on fields of endeavor and no discrimination is a pretty basic tenent that goes back a long long time (the DFSG were published in 1997, there are other things saying the same thing that pre-date it). I also know this is what other open s…

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 them. But I don't think it's my place, as a lawyer, to tell coders what "open source" should mean.

As for the old definitions, I've consistently overestimated how much devs care. Frankly, I've overestimated definitions focusing on license terms as a general proposition. Partly as a result, I've reassessed how I channel those projects, and my desire to belong among those invested in them, through my practice. Clients assume what I say is legally grounded. My job is to hear them and help them. Not to cite them under someone else's client's PR program, or scare them straight with the hiss of a hot "proprietary" brand.

Re: Commons Clause

#122

Post by mbrameld »

tschellenbach wrote: post #73
mindcrime wrote: post #55

This is pretty stupid. If you want to license your software under a proprietary license, just license it under a proprietary license. Or if you want to be "Shared Source"[1] use one of the old MS licenses for that. But don't try to put lipstick on a pig and add a veneer of "openness" by shipping something under an Open Source license + terms that make it very explicitly not Open Source. As much as I like Redis, and e…

I have no affiliation with Redis, it's clearly still open source, it's just not free for some of their users.

You may be confusing the actual definition of open source and the literal interpretation of the words "open source". Open source in the context of software doesn't just mean that the source code has been published.

Re: Commons Clause

#123

Post by mindcrime »

cookiecaper wrote: post #59
mindcrime wrote: post #55

This is pretty stupid. If you want to license your software under a proprietary license, just license it under a proprietary license. Or if you want to be "Shared Source"[1] use one of the old MS licenses for that. But don't try to put lipstick on a pig and add a veneer of "openness" by shipping something under an Open Source license + terms that make it very explicitly not Open Source. As much as I like Redis, and e…

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.

Re: Commons Clause

#124

Post by paxy »

toomuchtodo wrote: post #48
amelius wrote: post #39

Any software with a restrictive license of any kind will eventually be replaced by software with a more liberal license.

Who would waste thousands of man hours to write a Redis replacement for free, only to have it taken by large tech companies to rake in revenue through managed offerings?

You don't have to write a replacement, just fork Redis and continue from there.

Re: Commons Clause

#125

Post by [deleted] »

mark_element wrote: post #2

I don't like the naming. "Apache 2.0 with commons clause" is not the right way to describe this licensing paradigm. It is fundamentally no longer Apache 2.0. I appreciate the motivation, but think it would better serve everyone to just make a new "Redis License" that describes the terms.

[deleted]

Re: Commons Clause

#126

Post by kungfooguru »

pmilot wrote: post #41

Doesn't this Commons Clause goes specifically against one of the core principles of Free Software? The whole idea is that a Free Software license should not restrict what you can do with said software. Even the most restrictive FS licenses like GPL will not prevent me from selling consulting services around the product licensed under it. If you combine this clause with a Free Software license, it sounds to me like it…

Yup, it (whatever pieces are now under this new clause, it isn't clear, may just be some modules) is no longer free software.

Re: Commons Clause

#127

Post by cobookman »

justinjlynn wrote: post #111
dcow wrote: post #88

Earlier quoted context omitted.

They mention later on that redis core will always remain BSD. I share your sentiment, though it seems like this is an effort to not totally isolate the project. Their goal appears to be clamping down on straight up resale of integration components & modules.

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…

AWS elasticache Gcp memorystore

Neither use redis name brand, but both offer a managed redis

Re: Commons Clause

#128

Post by mrep »

bodas wrote: post #68

What a lesson in unintended consequences. The license is vague enough that Amazon & co can just lawyer up and ignore it. What are they going to do, sue Amazon? Good luck. On the other hand, it will definitely scare away users of their software who will be concerned that their CRUD app derives "substantial" value from it and is thus infringing.

Big companies do not like vague licenses. I work at a big tech company and I was specifically told to not use any software under the WTFPL license (Do What the Fuck You Want To Public License) [0] because it is not explicit.

[0]: https://en.wikipedia.org/wiki/WTFPL

Re: Commons Clause

#129

Post by mattdeboard »

justinjlynn wrote: post #111
dcow wrote: post #88

Earlier quoted context omitted.

They mention later on that redis core will always remain BSD. I share your sentiment, though it seems like this is an effort to not totally isolate the project. Their goal appears to be clamping down on straight up resale of integration components & modules.

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.

Re: Commons Clause

#130

Post by toomuchtodo »

tomnipotent wrote: post #95
XiZhao wrote: 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…

> 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, in the case of Redis) in creating the product?

What will you do as a technology practitioner if more projects move to this model to provide some semblance of financial support for their devs? Write your own RDBMS? Your own in-memory caches? I won't discount these paths as impossible, but it increases your costs and time to market significantly.

Standing on the shoulder of giants is both efficient and convenient when building your product/stack by bolting together existing tooling (what products aren't using Redis/Memcached, MySQL/MariaDB/Postgresql, ElasticSearch, etc), but it should have a cost; those shoulders aren't free, and it's not reasonable that those enjoying easy revenue (AWS, for example) by providing managed services with these tools don't have to share that revenue. You can't freeload forever.

Post reply on HN