Commons Clause - <AUTHOR> https://redislabs.com/community/commons-clause/ <comment><USER2> Hi folks. Kevin from [http://fossa.io](http://fossa.io) here. I worked on bringing the Commons Clause to life ([https://commonsclause.com/](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's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.

2/ OSS projects are mainly funded by some proprietary offering or service on top of it. Anything to help the ability to monetize this layer is really good, as the fate of the project is directly tied to this revenue stream. A quick reminder, companies like Redis sink 10s of millions into RnD and are usually contributing over 99% of the code to these repos.

3/ OSS-savvy companies aren't dumb. They understand the optics of any licensing announcement and carefully consider what it will mean. Before we react, we should push ourselves to understand what systems are forcing deeply passionate OSS devs to consider more proprietary options.

<comment><USER3> 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 source lawyers are saying as well (in fact, i haven't seen _one_ who believes it is anything else).

I'm sure you can make up another word other than "proprietary" to call it, but ...

As for questions: The main commons clause page makes the claim "Initiated by a coalition of top infrastructure software companies to protect their rights"

Care to list them?

Additionally, even ignoring the significant vagueness in the clause, there are plenty of combinations of licenses with which this clause makes literally no sense. It seems there is no guide or policing of these. Truthfully, this all does not feel well thought out. Who actually participated in the drafting?

Here is one that exists in practice:

neo4j is commons clause + AGPLv3

AGPLv3 section 7: If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.

...

GPLv3 is identical in this respect, and LGPLv3 is a set of permissions on top of GPLV3 that does not revoke this clause.

This seems to make commons clause incompatible with a lot of software.

<comment><USER4> I've never heard of an open-source lawyer. I understand totally how valuable it is to litigate open-source issues, but I'm curious as to who pays for such services? Being able to pay lawyers seems unlikely for a free product.

<comment><USER5> 10 out of 10 of the largest tech firms in the world release significant opensource software: Microsoft, Apple, Amazon, Google, Facebook, Alibaba, Intel, Oracle, Samsung and Baidu. They turnover more then $1 trillion and use many lawyers.

</comment></comment></comment></comment><comment><USER6> Weird. Company full of Open Source guys, but I think they didn't get the right advice on a business model. The reason why MIT/BSD/Apache licenses are there is that there's a group of people who want to let companies use their stuff. If you want people pay you, you just release commercial software, without showing the source. License is something that once put in, it's too late to change later, and not disrupt how your technology is used in the field.

e.g.: I was contributing to FreeBSD because I wanted to contribute to BSD licensed-software, with a hope people from FANG would use it, and maybe hire me later. If FreeBSD made a chance to the license, it'd no longer be FreeBSD. It'd be FreeCommonsClause--different project. I wouldn't like to contribute to this.

As a CEO fo a software company, if I were to go and analyze what this license change means to my business, and probably get uncertain answer, I'd rather fork Redis from before the license change, and run on the copy.

Why? Because the fee for a US software engineer is $X, for a over-sees is $0.3X or $0.5X. Fee for a US copyright lawyer with expertise in software is 10$X. Pay that much money for no value-added to my business makes no sense to me.

<comment><USER7> Sorry for spamming this all over the post, but I think it's important enough for everyone to see this:

Redis itself IS NOT changing licenses, and if you only use the core Redis product you are unaffected. This license change only applies (or _will_ apply, I guess) to some source-available addon Redis modules. (I'm not sure if any existing open-source modules developed by Redis Labs will have their license changed, or if this will only apply to modules published after the announcement.)

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

<comment><USER8> Since you're spamming this everywhere, I'll repeat _my_ concerns.

1) Some of us no longer trust the company not to bait-and-switch again. 2) It's almost guaranteed that at least future useful developments will happen under the proprietary and consulting-encumbered license.

I'll admit the company has every right to execute on #2 - t is 100% without doubt going to have me reconsidering our use of redis here, and keeping a very close eye on what Amazon and Google (and others) do in response to this, as I decide what alternative to the consulting-encumbered software we might use going forward.

<comment><USER7> Re. 1, that's a fair point. For what it's worth, the blog post does explicitly promise, in writing, that Redis itself will remain BSD-licensed forever. Take that for what you will, since I certainly don't have any more info on their intentions than you do (and probably would be prohibited from talking about it if I did), and you have no reason to trust me any more than the blog. I believe a written commitment under a company's official domain should at least have some legal weight, though IANAL.

Re. 2, I /personally/ believe the BSD-licensed Redis itself will continue to be developed and improved as before, but I hope you appreciate why I'm being very cautious about what I say. I'm not really positioned or authorized to make any statements on behalf of Redis Labs.

<comment><USER9> > believe a written commitment under a company's official domain should at > least have some legal weight, though IANAL.

It doesn't. It's a promise made by someone who just reneged on another implicit promise.

</comment></comment></comment></comment></comment><comment><USER10> 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 License, as defined below, subject to the following condition.

Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.

For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Cause License Condition notice.

<comment><USER11> >substantially

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

<comment><USER12> It's something that would be decided by a judge or a jury.

<comment><USER13> 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).

</comment></comment></comment></comment><comment><USER14> 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.

<comment><USER15> The name is kind of implying that it's somehow related to Creative Commons. I assume the latter organization actually has nothing to do with it?

<comment><USER16> Yeah... I'm interested to know why they picked they been.

</comment></comment></comment><comment><USER17> 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 is no longer FS. You can't have your cake and eat it too.

<comment><USER18> > _Even the most restrictive FS licenses like GPL will not prevent me from > selling consulting services around the product licensed under it._

At least this doesn't prevent _buying_ those services. If I obtain the program from some party A, then A redistributed it to me. Then if I contract B to work on/with the software, B is not bound by the contract because they did not redistribute it to me. However, though I can pay B, neither of us can sell the enhancements though, if enhancements were made.

Moreover, I can't use the software to run any kind of business, because that's might be a product or service that arguably derives substantial value from the software.

</comment></comment><comment><USER19> > _but all other users will be unaffected by this change._

This is untrue for the simple reason that you will be unable to apt-get install this software directly from Linux distros with a policy of including only FOSS.

Or, more generally - the value of FOSS is in the opportunities for public collaboration and redistribution. If you think you're doing the vast majority of the development work anyway and you want people to get packages from you anyway, great, there's no need for an open-source license at all: just provide source, allow people to make private modifications, and allow people to send fixes back to you. If you value the open source ecosystem, though, cutting yourself off from it is a bad plan.

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

<comment><USER21> 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's really unhelpful for the rest of the community. We're going to spend a lot of time trying to clarify for people who don't understand the implications of these toxic licence provisions why they make such components unacceptable.

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

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

<comment><USER22> This is absolutely not Redis rent-seeking. In fact, what the Commons Clause is designed to protect against, from my lay-reading of it, _is in fact rent- seeking_.

As for the rest, the Redis Labs post addresses every point you make pretty definitively. I don't think many of the people who are bothered by this business decision read that post. And if they did, and they comprehended it all, but they still think Redis decided poorly, then I think there's a different convo to have. A broader one about values.

Or... hey, maybe they're just not as cynical as me. Maybe they don't think it's plausible companies are out there right now selling their "Redis with a few bells & whistles" product. Then it stands to reason that you'd see the Commons Clause as some kind of enablement to somehow rent-seek from innocent corporations. I mean hell I'd prefer that. If that's the case then I'd probably share that person's opinion about Commons Clause.

I just don't think that's the case. I believe Redis is making this licensing change in good faith. Not because I know anything about Redis that leads me to believe they're honest people. But because a product team lazily putting together a product at AMZN or GOOG or whatever else and not even thinking to look at the Redis license sounds pretty realistic to me!

Occam's Razor would say this is not an elaborate scheme by Redis to extort Fortune 500 companies.

<comment><USER21> > But because a product team lazily putting together a product at AMZN or GOOG > or whatever else and not even thinking to look at the Redis license sounds > pretty realistic to me!

No.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> > 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.

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

<comment> another-cuppa 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.

<comment><USER25> It's not just fashion. It's a question of "Do I want someone to use my software?", because with GPL the answer would be no for a lot of projects.

<comment> another-cuppa Why do you think that? Linux is the most widely used operating system in the world and it's licensed under GPL. People don't choose not to use software because it's GPL. Why would they?

<comment><USER26> You're mistaken. (Well, maybe not mistaken if I read exactly what you said literally, but people/companies most certainly do choose not to use GPL software if they're looking to build a system that they can exploit for profit-making purposes.)

It takes a very forward-thinking person to understand that they have more to gain from the thousands of eyes and the support of the community, than from a paywall that gates access to their creation. (And that person could reasonably choose to license their software as GPL or any other open license, there are lots of trade-offs.)

But if you're not building the system from scratch, you need to be aware of the licenses you've accepted, and for many businesses the addition of GPL software to the stack will be a non-starter. Do you think we'd have Apple as it is today if it wasn't for BSD Unix and the BSD license?

<comment><USER27> Would we have Android today were it not for GPLv2 and Linux licensed under it?

But indeed, GPL _does_ limit the ways you can distribute software licensed under it. In particular, licensing something like a library, or another early- bound component under GPL forces the users to license their work under GPL, too. This is why LGPL exists.

<comment><USER26> Absolutely! Not saying that Apple model is right or wrong, but they certainly chose BSD consciously (whether or not it was because of the encumbrance of GPL, or any technical reasons).

It's simply wrong to say that nobody pays attention to this. It's a choice you make, and whether you view the consequences as "repercussions" or "features" depends entirely on your view and the actual outcomes of those choices.

Fwiw I understand that Darwin is also available as BSD, so it seems you can get some good actors that are willing to pay it forward without necessarily needing to add a license that goads them into it.

<comment><USER28> Apple/NeXT had serious experience with the GPL license when shipping their GCC-based Objective-C compiler.

Their subsequent choice to use BSD-licensed components, and to support/create BSD-licensed components where only GPLed components existed, must be seen in the light of this experience.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> I clarified that the Redis core ([https://github.com/antirez/redis](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](https://twitter.com/antirez/status/1032180321834467330)

and the considerations thread:

[https://twitter.com/antirez/status/1032192721308594176](https://twitter.com/antirez/status/1032192721308594176)

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

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

<comment><USER30> Our use-case would be installing Redis with Disque on our servers (VPS) to run it for our own infrastructure. Job queues n such. Not sell it to other users as "hosted disque" etc. Is that a use case you are against too?

<comment><USER29> No the end goal is not to go against your use case, but as a side effect AGPL will actually remand even this use case to make the changes available.

<comment><USER31> To be clear, you are referring to changes to Disqueue code itself and not any code or service that communicates with with Disqueue via its APIs, or the configuration that I use when launching Disqueue (e.g. my disqueue.conf).

Said another way, if I make a patch to the binary that I compile to, for example, fix a bug that isn't yet in upstream or to add a feature that isn't yet in upstream, I must make those changes available as per AGPL.

Is that understanding correct?

</comment></comment></comment></comment></comment></comment><comment><USER32> To be fair, Redis itself still remains BSD licensed.

The other modules for Redis developed by RedisLabs [1] are under the new Commons Clause license.

The big 3 cloud providers provide Redis as a cache service and don't use these modules anyway, so their offerings will remain unaffected.

[1] [https://redislabs.com/community/oss- projects/](https://redislabs.com/community/oss-projects/)

<comment><USER33> I wonder if it will follow the path of Android: start with a huge open source base and some propriety bits on top, and as they go on, move more and more of the functionality to the propriety part until the open source part is useless by itself.

<comment><USER32> that definitely seems to be the plan. this is the first step towards it.

</comment></comment></comment><comment><USER34> 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...](https://aws.amazon.com/blogs/opensource/open-sourcing-encryption- in-transit-redis/)

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](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?

</comment><comment><USER35> Yikes, the wording around consulting seems especially worrisome - are they effectively prohibiting third parties from providing redis technical support? This move will likely kill the project as it is today.

<comment><USER36> This is limitation around selling software/product not consulting, per bottom of post:

"...if your product is an application that uses such a module to perform select functions, you can use it freely and there are no restrictions on selling your product. However, if what you sell is basically the functionality of the module packaged as a cloud service or on-prem software, Commons Clause does not allow it."

<comment><USER10> Consulting is specially called out in the actual license as a no-no: "including without limitation fees for hosting or consulting/ support services related to the Software"

</comment></comment></comment><comment><USER37> 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.

<comment><USER38> 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

<comment><USER39> 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)

</comment></comment></comment><comment><USER40> The primary target here seems to be cloud hosting companies that provide Redis-as-a-Service. But the seemingly wide definition of Sell, including how consulting/support services are mention makes me confused. Can I as a software developer working as a consultant, still create an app for customers which uses Redis with modules under Commons Clause?

...the License does not grant to you, the right to Sell the Software. For purposes of the foregoing, "Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or __consulting /support services related to the Software __), a product or service whose value derives, entirely or substantially, from the functionality of the Software...

One of the nice things about MIT/BSD/Apache over GPL/LPGL was the ability to use a software without needing to involve lawyers. This might just have gone out the window...

<comment><USER41> Yeah it's awful. But in answer to your question: Maybe.

It looks a lot more forgiving if you flip it over from "what do they say I can do?" to "what could I get away with?". They'd have to find _you_ first. Then prove you were paid. Then they'd have to prove that use-case was _substantially_ dependent on their software.

Unless your employer went to Redis an announces all this, their ability to go after consulting/freelance developers is very limited.

I think this is, as others have said, a cash-grab at the cloud market who advertise these sorts of services publicly. They're easy targets.

<comment><USER42> "what could I get away with"

Seems like an awful thing to build your business around.

</comment></comment></comment><comment><USER43> >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 back _your_ improvements to the community for _our_ benefit.". Without this safeguard, progress and shared good is not achieved.

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

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

<comment><USER46> 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).

<comment><USER45> In practical terms, AGPL _would_ do it because far fewer people are willing to touch AGPL'd code.

And the start of this specific comment chain wasn't about "make money", it was about ensuring cloud providers "give back" their improvements.

<comment><USER47> In the case of Redis and the handful of cloud providers, I'm pretty sure they wouldn't leave millions on the table just because they're anxious about having to run it by legal.

</comment></comment></comment></comment></comment></comment><comment><USER48> Practically, since the core still doesn't have this clause, I imagine cloud providers will still offer hosted Redis, but will develop their own modules to install or allow people to install them themselves, since they can't offer the ones developed by RedisLabs on their own

</comment><comment><USER49> 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.

<comment><USER50> 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](https://en.wikipedia.org/wiki/WTFPL)

<comment><USER51> WTFPL is acceptable to IBM, though.

I bet that this new license isn't. It's radioactive.

</comment></comment></comment><comment><USER52> 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 even though Core is still under a plain old OSS license, these shenanigans would make me very suspicious of RedisLabs and reluctant to ever do business with them, or use Redis at all. :-(

[1]: [https://en.wikipedia.org/wiki/Shared_source](https://en.wikipedia.org/wiki/Shared_source)

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

<comment><USER3> It's clearly _not_ open source. It meets no definition of open source that has ever existed. Even other things like the debian free software guidelines (which date back to 1997. Seee [https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...](https://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines)) would not consider this free

It's also clear the goal is to "seem" open source by reusing the license names of open source licenses.

<comment><USER54> Can you point me to the line in the license file that clearly demonstrates Redis is not open source? [https://github.com/antirez/redis/blob/unstable/COPYING](https://github.com/antirez/redis/blob/unstable/COPYING)

<comment><USER55> As noted even in the initial comment in thus subthread, Redis itself is not under this new license, and thus still Open Source.

</comment></comment></comment></comment></comment><comment><USER56> There's a lot of fuss in these here comments about the future of Redis itself.

From the post (emphasis mine):

> Consequently, we decided to add Commons Clause to _certain components of_ > open source Redis. Cloud providers will no longer be able to use _these > components_ as part of their Redis-as-a-Service offerings, but all other > users will be unaffected by this change.

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

Isn't this, then, just another open-core play? The Redis you know and love, if you're most people (Redis core) isn't being relicensed. The Redis features ("certain modules") that these SaaS providers created themselves to provide on their platforms as value-adds, are being relicensed to be less BSD-y and more Microsoft shared-source-y ("open to contribution, pay to use", which is... wacky.)

Fundamentally, those modules were these companies' property to do with as they wished. Likely, they had few-if-any outside FOSS contributors (which is how they could get away with something like this in the first place.) They aren't some cultural touchstone of the community. They're proprietary vendor add-ons that happened to be FOSS-licensed up until now.

If these companies had _started_ with these modules being entirely closed- source (like with, say, Nginx's "Nginx Plus" modules), nobody would be batting an eyelash right now.

</comment><comment><USER57> This is a shame to apache's good name. Apache should never be mentioned in the name of a software version that isn't true opensource...

If you want to leverage apache and charge for it go ahead. Be a redhat or confluent, go nuts. Don't do this kind of bs.

</comment><comment><USER58> Trying to understand the motivation here.

In principle, what's the difference between my company taking advantage of open source software (cost savings, huge advantage because I don't have to build everything in-house) and a company that offers a hosted version of said software?

In both cases, I am benefitting economically and not contributing upstream.

<comment><USER59> The difference is that Redis Labs competes with one type and doesn't compete with the other. That's the only difference.

I'd love to hear Salvatore Sanfilippo's take…

<comment><USER58> Oof.

</comment></comment></comment><comment><USER60> 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.

<comment><USER58> How is this different from a startup using open source software (cost savings) instead of building everything in-house?

In both cases, the startup benefits and the project doesn't receive upstream contributions.

<comment><USER55> The startup doesn't compete with Redislabs, so it's not contributing, but also not hurting.

</comment></comment></comment><comment><USER61> Oh noes. This opens a terrible precedent for Redis core.

As acknowledged in the announcement, adding restrictions is against the spirit of open-source. No exceptions.

</comment><comment><USER62> If this clause comes to Redis Core, will it mean Heroku and others cannot offer me the simple hosted Redis they do today? Thesd cloud providers are exactly what makes Redis attractive to me, dramatically reducing the cost of spinning up new infrastructure for projects.

<comment><USER63> If you read the article, it implies that people like Heroku and others offering hosted Redis is EXACTLY the kind of thing they are trying to prevent with this clause.

To quote: "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. Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them. Already, this behavior has damaged open source communities and put some of the companies that support them out of business."

<comment><USER52> _If you read the article, it implies that people like Heroku and others offering hosted Redis is EXACTLY the kind of thing they are trying to prevent with this clause._

The thing is, the AGPL already existed for dealing with the whole "cloud vendors turning things effectively proprietary" issue.

<comment><USER55> But the issue doesn't seem to be "cloud vendors turn things effectively proprietary", but rather "cloud vendors offer the same services we want to offer, so we don't get the income that's paying for our development work". A cloud vendor can just run AGPL software and offer it as a service if they share their modifications (if any). They can't do this with software under this new license.

<comment><USER52> True, but in practice, may companies seem reluctant to offer commercial services with AGPL software. And at least with the AGPL, they are required to give back their changes, which helps the project. Granted, not all firms will be making changes, but still, I think the AGPL is better than this "Common Clause" thing, which is basically pretending to be something its not.

</comment></comment></comment></comment></comment><comment><USER64> > 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 used this way, otherwise I wouldn't put it out there. Granted I also disagree in many cases with copy left licenses. I don't want to engage in that debate here, but suffice to say some people want to control what you do once they transfer stuff to you and some don't. You see it a lot in non software these days too. We need a new term called "restrictionless software" or something similar so those of us with small companies don't need lawyers to share and share alike when each version of this type of clause comes out.

In the meantime, building a company out of charitable software work is probably hard, so I'm sure others' revenues off your stuff feels wrong. And it's hard to maintain a sense of freedom but still add pay-for features, so I sympathize with companies going this route.

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

<comment><USER66> > 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'.

</comment></comment></comment><comment><USER67> I look forward to telling my consluting clients that it's illegal for me to take a Redis gig, but I can help them migrate to another key-value store.

</comment><comment><USER68> I don't think this is going to work out the way redis wants it to. Most likely, this will cause a fork of whatever "modules" they have applied the new "Commons Clause" to and everyone will continue on pretty much as before. It will also most likely alienate existing community members and dissuade people from contributing back - they may even lose important contributors over this.

</comment><comment><USER69> So I just want to ask about clairification. I am leaning toward liking this as it solves sole practical concerns for these types of businesses and projects but one small thing I'm struggling to understand is how it affects trainings and or consulting where you derive your income teaching people or integrating people with these systems

The language around that was very legalese if anyone has opinions

<comment><USER7> IANAL, but my understanding is that as long as you only provide the knowledge but not the actual software you're fine. e.g.: conducting paid training sessions, even ones where the attendants are required to download the software from the official site and install it on their machines for practical exercises, should be okay. If someone wants to pay you to install licensed software on their production machines and configure it... Eh, probably not.

Also to reiterate that Redis itself is still BSD, so if you're not using add- on modules licensed with this clause you're unaffected.

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

</comment></comment><comment><USER70> So if you're a cloud provider that provides generic cloud VMs, with a button to "Install Redis onto VM", is that allowed? What if it's one of hundreds of similar buttons to install various software onto the VM?

What if there's no button, but a user can run `apt-get install redis`? Is that in violation?

<comment><USER71> That is allowed and fine. What you can't do is, if you are Amazon, release "AWS Sdejt" which is simply a managed wrapper around Redis.

<comment><USER72> Can you explain how you interpreted the license to say that's fine? Isn't the value of the service "substantially" its ability to run redis? And isn't the package manager a form of distributing redis? (Referring to the shared source modules, not the BSD licensed part)

<comment><USER8> This is the problem (at least for me) - the wording is vague and open to interpretation, which means if it ever needs to be clarified, it'll need expensive lawyers to get that done.

A reasonable man would say "Of course the value of, say, Digital Ocean's service is not "substantially its ability to run redis" \- even though any linux vm customer can run their OS choice's version of 'apt-get install redis'".

But we do not live in a world were a "reasonable man's interpretation" is an acceptable risk-mitigation for a business.

I'm pretty sure there'll be other people who, like me, are considering how best to risk manage the use of redis going forward...

<comment><USER72> Luckily the core redis server is still open source. It looks like they've taken the nginx plus business model and combined it with shared source.

</comment></comment></comment></comment></comment><comment><USER73> For clarification, here's the official response from the Redis Labs's website: "the license for open source Redis was never changed. It is BSD and will always remain BSD." Only Redis add-on modules developed by Redis Labs have changed from AGPL to Apache v2.0 modified with Commons Clause. [https://redislabs.com/blog/redis-license-bsd-will-remain- bsd](https://redislabs.com/blog/redis-license-bsd-will-remain-bsd)

</comment><comment><USER18> The "do not redis dis" warning label.

Software with this clause is not usable in the real world.

The clause's strictest interpretation prohibits all business use.

 _Sell" means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting / support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software._

So for instance, if I run, say, a travel agency or a bakery on software with this moronic clause, that's a product or service whose value derives substantially from the functionality of the software.

There seems to be no difference between this and "free for non-commercial use and redistribution".

</comment><comment><USER74> I think it's worth mentioning WordPress who have managed to successfully maintain an open source version whilst building their own cloud offering to profit from. Many other cloud services provide WordPress as a service, but WordPress are still able to maintain multiple streams of revenue through 'official' WordPress hosting.

<comment><USER75> That's a bit harder for Redis though, because to keep latency down you want it running in your cloud, not somewhere 10's of ms away.

Sure Redis could run clusters in every cloud provider's DCs, but then they're paying for the cloud like anyone else and costs increase.

</comment></comment><comment><USER76> Redis is no longer free and open source software with this move. It is now proprietary software.

<comment><USER71> Pragmatically, this is still open source software, because the software source is freely available.

It might not be Open Source Software now, perhaps according to some zealots like RMS et al.

> According to the Open Source Initiative (OSI), open source licensing cannot > limit the scope of a license – it only applies conditions to exercising it. > With this model, no one can stop you from doing whatever you want with the > software, whether commercial or non-commercial, or (famously) good or evil. > Therefore, the no-sale restriction imposed by Commons Clause means that any > software under this new license is non-open source by definition. However, > in practice, Commons Clause only adds a limitation concerning fair use, and > we believe that both licensing approaches share the same core value of > making software available for use by anyone.

<comment><USER77> > Pragmatically, this is still open source software,

No, it's free of charge shared-source software. The OSI and FSF open source and free software definitions are virtually identical despite their very different philosophy because any less freedom than they call for quickly collapses the benefits of the arrangement.

<comment><USER78> I'd say GP is correct, but only insofar as that Redis Labs hasn't changed it yet:

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

</comment></comment></comment></comment><comment><USER79> Question : isn't the prohibition of consulting, too close to definition of non-compete that it is effectively nullified in states like California ?

Yes, I know this is just for one particular software - but this could have been made for an "algorithm" as well, which has already been tested in courts.

</comment><comment><USER80> Just dual license with AGPL, instead of this proprietary crap.

<comment><USER81> Agree, the Affero GPL works for the cloud scenario:

"It provides the same restrictions and freedoms as the GPLv3 but with an additional clause which makes it so that source code must be distributed along with web publication."

</comment></comment><comment><USER53> This seems aimed at cloud hosting provider that currently get the tech for free. Makes sense in a way.

<comment><USER82> Yeah, but its not like they are "getting it for free". It is a ecosystem, and cloud providers have provided many nice things back to the ecosystems. Including jobs to many prominent OSS developers. Not to mention cloud providers do the most important sort of work on any project. That is running it reporting bugs and often submitting patches to those bugs. Larger cloud providers even hire people for the sole purpose to work on said OSS projects simply to improve them.

<comment><USER83> I get what you're saying but Redis found popularity way before clouds started offering it.

Clouds later further contribute (and profit) to the ecosystem, but make no mistake they didn't help create or spend any resources for that ecosystem.

Redis is probably the number one kv store atm, not sure what the number two is, and for sure no clouds are offering it right now; but if this licensing thing goes sour with the community - you can be sure that

a) a fork will happen or the number two will gain popularity b) that replacement once enough customers ask for it will get added to the clouds c) the clouds again - with no initial investment will derive value

Basically the moral of the story is, be a cloud provider.

<comment><USER82> I disagreed, partly on the what makes the "ecosystem". While Redis has its own micro ecosystem it is NOT the entire ecosystem. While there may not have been direct exchanges on the level you described Redis did benefit from having the larger ecosystem to work within.

Does the fox owe the worm for the fish it had for dinner because the fish had the worm for lunch?

Basically you can't isolate yourself from the entire ecosystem and cry foal. When you fail to see the benefit.

</comment></comment></comment></comment><comment><USER84> 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](http://boringtechnology.club)

</comment><comment><USER85> The naming of this is wrong and should be changed quickly and I'll explain why.

Commons Clause (abbreviated to CC) conflicts with Creative Commons (also CC). Creative Commons also has the word Commons which refers to a more established and well known thing. Commons Clause goes against the principles of the actual commons. it has nothing to do with a commons, or what is widely understood as "the commons". Call it something better - call it a proprietary clause instead. Maybe it's aim is to stop the "tragedy of the commons"?

</comment><comment><USER86> I'm not a lawyer but the first reaction to this was if it is enforceable at all? There is a [rich choice] ([https://tldrlegal.com/](https://tldrlegal.com/)) of licenses backed by court history and many years of practical usage.

For my OSS project I spent some time to pick a right license and changed it couple of times (LGPL -> GPL -> MPL 2.0). My final choice was mainly due to the blog post by author of ZeroMQ Peter Hintjens ["How to Make Money from Open Source"] ([http://hintjens.com/blog:27](http://hintjens.com/blog:27)) , where he described a story of "Patrick" who "told big companies that they could" rip him off and they did - in the spirit of the top comment here.

I have faced a troll on GitHub who opened an issue on almost every project related to data analytics and asked authors to change any reciprocal license to MIT/BSD/Apache. I've never seen him contributing anything substantial back. This was a refreshing reminder that as soon as I publish my code as MIT et al. all valuable parts from it will be ripped apart immediately and I'll unlikely see any contributions back. Yet I wanted to share my code and see contributions back. In the [issue thread]([https://github.com/Spreads/Spreads/issues/6](https://github.com/Spreads/Spreads/issues/6)) Peter Hintjens joined and commented that "MPLv2 gives us [ZeromMQ] the same benefits with less angst for corporate users" vs (L/A)GPL.

Many licenses are carefully crafted by lawyers and any change to it makes software not an open source anymore. It feels to me that OSS with a proper license is very close to a legal entity a la trust, and maintainers are just trustees. So if I want to remain any control I would rather choose uncool APGL.

</comment><comment><USER87> > if what you sell is basically the functionality of the module [...] Commons > Clause does not allow it.

Great ! Now the entire industry is accepting the "freemium" model where the core features are free , but not the modules around it.

This is a push to milk companies with paid licences on Free Software. This is insane that this is becoming the norm in the industry.

Every single day open source is getting less and less open. This type of constraints are insane and are similar to the one forced by Oracle.

<comment><USER88> It's one vendor contributing some modules which now they have a different license.

I don't see how this impacts any other Redis module on github out there.

Either those modules are that good and the vendor decides that cloud providers must pay and not get money from the vendor's work, or those modules are not really that used so who cares.

I have used RedisJSON module which is nice and I assume changes license now. Am I a service provider? Do I care about one module changing license so AWS and other clouds cannot use for their own service?

I couldn't care less and it does not impact Redis open source project _at all_ IMHO

<comment><USER87> > I couldn't care less

Let's say you are PHP consultant , you set up a Redis + EC2 instances.

You enable a redis enterprise module in that instance.

Well technically speaking you are breaching the license of RedisLabs. You are not allowed to do so without their consent because those modules aren't "bsd" or "mit" they are "Commons Clause".

In short , if you are doing something with the RedisLabs modules ( consulting / hosting / training / support ) you owe $$$ to RedisLabs.

<comment><USER88> It's unenforceable. European Union cannot claim VAT from smaller - yet big enough - foreign companies and is only targeting the very big ones to collect it from. I used to play an online game and, if you changed your country to a non EU one, no VAT was paid. And that was a big company that should have been enforcing EU VAT for me.

Would Redis Labs go after Joe and his brother? Even if the license said so? They're after the big abusers, not the community.

If I'm not mistaken antirez said so too, that it does not affect you and me. That's the reasonable thing anyway. AWS is the big abuser. Check MongoDB or Xen or Elastic cases. People (ex employees typically) are starting to talk how AWS is abusing their open source work. I think that's the whole juice of the story, that AWS is abusing successful open source projects.

At least that's what I read behind the words.

</comment></comment></comment></comment><comment><USER89> Aw, man. We yelled at the Redis dev so often for poorly reimplementing distributed consensus algorithms that he switched to poorly reimplementing software licenses instead.

</comment><comment><USER90> If someone could explain, what is the difference between what redis is doing and what nginx does with nginx+plus? I feel like most people use nginx still.

<comment><USER91> Nginx doesn't call it open source

</comment></comment><comment><USER92> I too like most commenters here think this is odd or weird and feels not open source.

Someone will just fork redis and remove the common clause is my guess as to what should happen?

weird

</comment><comment><USER93> Wow, so many negative comments here. I for one applaud the move -- a license like this has been needed for a long time.

Slightly (un)related, but I don't understand why in a forum full of software developers it is the consensus that all infrastructure software must be free (as in beer)? What are you guys planning to live off once that dream has finally been realised?

<comment><USER94> Consulting around open source software seems to my industry-new experience how people tend to make a living around open source software.

Correct me if I'm wrong, but isn't that how the core Linux folks make money? Or the organization running node?

<comment><USER57> Try anyone who works at a big company saving money by replacing vendor tools with custom open source solutions. There are a million ways to monetize open source, even as an individual.

</comment></comment></comment><comment><USER95> Maybe it's just time to crank up the revenue to make this worthwhile.

[https://redislabs.com/press/redis-labs-secures-44-million- fu...](https://redislabs.com/press/redis-labs-secures-44-million-funding-led- goldman-sachs-private-capital-investing-strengthen-database-leadership/)

</comment><comment><USER96> Any software with a restrictive license of any kind will eventually be replaced by software with a more liberal license.

<comment><USER97> 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?

<comment><USER98> The person who needs a Redis replacement but isn't interested in selling something that isn't core to their business and wants some assistance in the development from other people who are like minded.

They may or may not be a fool but their are more returns than just licensing fees for such a project prestige and it's effect on hiring for a company. Developer happiness. Other similar intangibles.

<comment><USER97> It seems to me, in the long run, it'd be cheaper to pay Redis for whatever they offer instead of attempting to craft your own solution, maintain it, and find others who also will maintain it. Developer happiness and exposure doesn't pay the rent.

</comment></comment></comment></comment><comment><USER99> Gotta say, stuff like this is getting a bit more common. Last month while I was evaluating choices for an application gateway I saw that:

* Ngnix has an enterprise version

* Kong has an enterprise version

* HAProxy has an enterprise version

Now redis as well, even if the commons license isn't quite as bad, it's a step back. It's understandable, but all a bit disappointing.

</comment><comment><USER100> If you don't want others to exploit your code without contributing back, don't use BSD/MIT/Apache; use (A)GPL.

Otherwise, you're just asking everyone to think you're a cool and mellow cat for releasing full-libre, man. But don't take my stash, dude. Not to mention crowdsourcing bug fixes.

</comment><comment><USER101> The license commit is very clear redis core is unchanged BSD 3 [https://github.com/antirez/redis/blob/unstable/COPYING](https://github.com/antirez/redis/blob/unstable/COPYING)

</comment><comment><USER102> I wonder what this means for Sidekiq.

</comment><comment><USER103> The P2P Foundation has some discussion on the topic: [http://wiki.p2pfoundation.net/Copyfair](http://wiki.p2pfoundation.net/Copyfair)

</comment><comment><USER104> This limits not just huge cloud providers bit also little startups. In fact, Redis Labs would've probably never been founded if Redis had come with this clause from the beginning.

<comment><USER2> That's true, but Redis is not closed source. This only applies to a few enterprise modules.

</comment></comment><comment><USER105> 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

</comment><comment><USER106> I would think a lawyer could poke enough holes through a Commons Clause license for it to resemble swiss cheese afterwards. I am not a lawyer, but software you get is under one license or another. Some are dual licensed, but you choose which license you are operating under when you publish your derivative work.

Base on what I read it's either Apache License or Commons Clause, not both. And if it's Commons Clause then it seems misrepresentation to say 'license: Apache License', as the example gave.

I think GPL has gone out of fashion, in some circles, because of fear. I work in a shop where GPL is outright forbidden, except where absolutely necessary, because of horror stories senior management has heard that exaggerate the risk of using GPL software, and because of real experiences.

I know of one such experience myself, according to my friend, his team was forced to rewrite an entire software package to use the Postgres JDBC driver and Postgres-specific migration scripts, because they were told MySQL driver use an redistribution did not require them to open source their code, and then they were told something different by a second member of the MySQL team. Shortly after that a memo was sent to all teams at that research lab, ordering no further use of GPL software except where no other option exists (and with lots of legal documentation in that case).

If you can deal with a service model for your business, then open source your software with BSD or other permissive license and sell consulting services. If you want a product model, then the one I see repeatedly work well is an open source core with enterprise commercial add-ons.

Mentioning consulting in the license further muddies the water. I know I was thinking of using Redis for a new project with a client, and now I won't. I won't be using Redis again until this license gets changed, and I encourage everyone else to do the same.

In today's security environment, and with software quality issues being what they are, I think having all your software be closed source, or restrictive non-free open source, is going the way of the dinosaur.

This Commons Clause seems to me to be a open source license, but seems restrictive and a step backward. The wording coul be taken to be deceptive. And calling it 'Commons' anything is adding insult to injury.

</comment><comment><USER107> In other news I suspect someone will soon be forking Redis and development of an open source/free software fork will continue...

<comment><USER108> The license for Redis itself has not changed and will not change, I doubt there's a need to fork it.

<comment><USER109> There was such a need for ownCloud, where the company and main maintainers pushed developers to _not_ develop things in core which would compete with their proprietary extensions. [https://fosdem.org/2018/schedule/event/nextcloud/](https://fosdem.org/2018/schedule/event/nextcloud/)

</comment></comment></comment><comment><USER110> [https://xkcd.com/927/](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.

</comment><comment><USER111> TL;DR redis is no longer open source. I wonder why that's not the title of this post.

<comment><USER112> Perhaps you should read it, your TL;DR is incorrect.

What the post says is that Redis add-ons won't be open source, but the core will be (which is Redis).

Basically this is a Open Core business model and they could have been clearer in their announcement because looks like a lot of people don't quite read announcements.

</comment></comment><comment><USER113> Sounds like MBAs and lawyers are swooping in. Abandon ship.

<comment><USER6> It'd be much better if they asked people who understand business of open source on how to drive more $.

For example: it could as well be: "If you're any of: FB, APPL, MS, .... and you use this software in your cloud, you owe us $2M/yr"

It'd be much easier to analyze the impact.

<comment><USER114> that would be discrimination and that's would also make it a non open source license

 _5\. No Discrimination Against Persons or Groups

The license must not discriminate against any person or group of persons._

[https://opensource.org/osd-annotated](https://opensource.org/osd-annotated)

<comment><USER109> The freedom definition doesn't have such a requirement though. Sometimes it allows to prohibit some usages, e.g. [https://www.gnu.org/licenses/license- list.html#OpinionLicens...](https://www.gnu.org/licenses/license- list.html#OpinionLicenses)</comment></comment></comment></comment>


Peter Thiel's CS183: Startup - Class 14 Notes Essay - <AUTHOR> http://blakemasters.tumblr.com/post/23787022006/peter-thiels-cs183-startup-class-14-notes-essay <comment><AUTHOR> This series has been some of highest quality material I have seen in a long time regarding entrepreneurship. PG's writings are pretty good too.

Anyone have recommendations for other writings covering similar topic material and with a similar signal-to-noise ratio?

<comment><USER2> Marc Andreessen's old blog posts.

<http://pmarchive.com/> <http://pmarca-archive.posterous.com/>

<comment><USER3> Yeah. I wish pmarca would have stayed in the game. I got a lot out of his short stint a few years back.

</comment></comment></comment><comment><USER4>
      But there was significantly more investment in cleantech
      than there was in the Internet during the last decade.

While said as an aside, if true, this is incredibly significant. Even if there is an internet bubble, it's hard not to argue that very real, visible progress has been made in web technologies over the last 10 years. Whereas the price of many forms of energy has (if anything) increased in real terms.

A glance at the numbers suggests that the government put more taxpayer money into Solyndra type companies than it did into web startups, and that this was one of the things that drew less scrupulous venture people to the area: use the dumb money from the government for an exit.

</comment><comment><USER5> Not specifically because of this article, but on reading the notes in the series, I am truly amazed by this level and clarity of thought. Is this even teachable or does it arise more out of experience, can one do something to acquire such clarity of thought ?

</comment><comment><USER6> I find it distressing that even PT has succumbed to this Orwellian use of the word "clean." CO2 isn't dirt.

The human instinct for hygiene is one of our most basic. When, as a calculated public-relations maneuver, you connect a scientific hypothesis (such as a climate model) to this instinct, you'd better make damn sure you're doing the right thing in every way, shape or form. I hope those models are well validated.

<comment><USER7> I get the feeling PT isn't a big believer in global warming, but the accepted term for those kinds of investments is "cleantech". If he called it "CO2-reducing technology investments", he'd sound like a curmudgeon who's more interested in being pedantic on the internet than being understood. ;-)

<comment><USER6> Sure. I wasn't harshing on PT - I'm a huge fan like all decent and reasonable people :-) In fact I'd be careful about attributing any kind of controversial position to him, but I must say defining thorium fission as "cleantech" is pretty clever - talk about dirt!</comment></comment></comment>


My Y Combinator Experience (Application, Interview, Decision) - <AUTHOR> http://brandonk.com/?p=219 A three part series covering my process at YC.
Application Interview Tips For Future Companies <comment><USER2> The first link in pg's email that you quote in your post asks to be kept confidential. You might want to redact it.

<comment><AUTHOR> Thanks

</comment></comment><comment><USER3> Nice post, but I prefer to see the whole story instead of having that break down in 3 days...</comment>


What do I learn next? - <AUTHOR>

I know Python and C. What do I learn next?<p>--edit--<p>I have not had formal training in programming so I am looking for languages which show me new things. <comment><USER2> Lisp. Specifically, try Scheme. More specifically, try working through _The Little Scheme_ and _Essentials of Programming Languages_ , both from MIT Press.

<comment><AUTHOR> I had been hunting around for Lisp tutorials and literature. I stumbled upon writing a lisp interpreter in python called Lis.py

All this while I had been thinking Lisp is something novel and only for kicks. Thank you for letting me know about Scheme.

<comment><USER2> There are other good Lisp dialects too, of course, but Scheme tends to be especially well-suited for learning the concepts of Lisp (or of computer science more generally), and has numerous good books towards that end.

Also, oops on a typo that I can't fix in my previous post now: _The Little Schemer_.

</comment></comment></comment><comment><USER3> SQL and database normalisation. Then datawarehousing things like star schema.</comment>


Cassandra on Mesos – Scalable Enterprise Storage – Mesosphere - steve-o

<comment> steve-o Great write-up thank you.

While experimenting with cassandra-mesos, I find myself making changes to cassandra.yaml, mesos.yaml often and restarting the scheduler, only if the active cassandra tasks are already running on the slave, they don't go away to be restarted.

What would be an elegant way to stop these "orphan" tasks executing on the slaves? Should that be the cassandra scheduler's responsibility or brute process termination by logging into each node?

If there is a recommended approach please share in the docs.</comment>


Equifax finds an additional 2.4M Americans impacted by 2017 breach - <AUTHOR> https://www.cnbc.com/2018/03/01/equifax-finds-additional-2-point-4-million-impacted-by-2017-breach.html <comment><USER2> I am fascinated to learn that Equifax will be reaching out to these affected 2.4 million individuals to inform them their personal information has been compromised. Equifax did no such action for the first 175 million people.</comment>


Ask HN: Do you believe in God? - <AUTHOR> I have always been intrigued by religion, specifically it's power to motivate, inspire and provide hope. Some of the greatest works (and greatest atrocities) have been carried out in the name of religion.<p>This got me wondering, do my hacker idols believe in God? Are they agnostic, like myself? Are they atheists? <comment><USER2> Perfect being is a psychological reality. Faith does not entail religion. Sartre pronounced himself an atheist, but wrote extensively about the problem of bad faith. You put your faith in others every day. The problems begin when you put your faith in systems, rather than subjects (read: Worlds). Make faith-investing a conscious process. What about this Subject am I taking/acquiescing to on faith? vis what I am taking as manifest (read: System). Faith in Subject is good, and in System, not so much. All Subject is good, and all System is for sale. Everything else is pronunciation and posturing.

<comment><AUTHOR> I love the concept of "faith-investing" and making it conscious. I believe that bringing consciousness to any choice makes the choice better; especially when it is something so deeply entrenched like faith.

Also, I feel this idea has merit in the realm of Entrepreneurship... In some ways it equates to risk. We can blindly take risks or we can carefully take risks. Realizing that there is an element of faith behind all decisions, being aware of "faith-investing" may make us less blind to the risks we take and allow us to be careful instead.

</comment></comment><comment><USER3> I believe in God, the same way people have believed in God for centuries: I believe in a God that is a series of forces that govern our world, many of which I can't explain or understand.

These forces for me are based on Science for the most part, and where science can't explain things, philosophy or just plain mystery. But to me, that's the same God Christians believed in 20 centuries ago, we just have better information now. They haven't adapted.

<comment><USER4> I don't want to try to start an argument or be insulting, but I don't believe you really grasp the question or the concepts you are talking about. Have you read the Bible to get a picture of who Christians think God is? That picture is rather incompatible with a "series of forces."

<comment><USER3> I have 2x and have made a semi-serious about the circumstances surrounding the writing and compiling of the various parts of what we call "The Bible"

Examples of how they fit my understanding laid out above

The Torah: How the Earth came about, why it came about, and the best ways to live in society governed by the first two. God, someone made in our image (we're the most intelligent beings we knew of, it was actually good science to believe without more proof that God would look like us), made the world, put us in charge purposefully (as we operate purposefully) and now here are some things that will keep society from falling apart. And you HAVE to do them because God said so (makes sense, keeps things simple and in order)

The Prophets: Why the fuck is everything so bad for the Jews? Because of something that will happen in the future, so don't give up faith. This makes sense given the context of the Torah and given the need to not give up hope.

The New Testament: The prophets said we'd have a savior, and he delivers: but only in the way he could. Leading a military uprising wasn't feasible at the time, but leading a spiritual one was: hey guys, given the context of the Torah and the Prophets, we're going to have a revolution but not of this world. Of the next.

</comment></comment></comment><comment><USER5> I'm an atheist myself (born Catholic).

I tend to borrow bits from secular humanism and Camus' existentialism, which tell me that in the end, you need to find your own motivation, inspiration and hope.

Large groups of people are all capable of great works and great atrocities (along with a myriad of smaller ones), religions just happen to be one of the many divisions of people.

<comment><AUTHOR> Thank you for sharing this great response! I've been tempted to look into Camus, perhaps I will revisit that undertaking. Any recommendations for literature?

<comment><USER5> Depending on your temperament his fiction can be either very insightful or a total downer. I've found his non-fiction like "The Rebel" to be very accessible especially as philosophical works go (Heidegger and Kant being the epitome of inaccessible to the non-scholar and even then ... ugh). Camus also worked as a journalist so that had an impact on his writing.

It is very intense to read Camus straight, so I usually alternate it with something more optimistic or at least humorous. If I'm going to face the absurdity of existence as a mortal human being, I at least need a laugh or two on the way.

I remember William Barret's "Irrational Man" being a pretty good overview of existentialist thought.

<comment><AUTHOR> Awesome, thanks again

</comment></comment></comment></comment><comment><USER6> Born and raised in a conservative, predominantly Christian Philippines, baptized and raised Catholic, hell I never went to a non-Catholic school my entire 23 years of life. Turned out to be agnostic, or whatever, I don't care. I just don't pretend to know what I really don't.

</comment><comment><USER7> I was brought up with somewhat of a southern baptist upbringing. My mother was a baptist and active in the church, as was I as a child, though she was not really very socially conservative. My father believes (when last I checked), but is not so much a supporter of organized religion. My husband falls into this same category.

I, on the other hand, am an atheist. My personal philosophies tend more toward secular humanism. I'm all for taking care of one another, just because it's the right thing to do. I think we have an obligation to one another to do so.

There are some Buddhist teachings that resonate well with me, but that's because they align with my sense of morals and ethics, not any sort of spiritual motivation.

</comment><comment><USER8> Nothing good can come of this topic (on a forum like this anyway)

</comment><comment><USER9> Yes I do.

His name is Bob and when he resets the computer we are all screwed.

</comment><comment><USER10> I am an gnostic atheist, I don't believe in any god and I feel that there is enough proof to show that gods do not exist.

Also, (a)gnostic and (a)theist are not a sliding scale, they are more akin to x,y coordinates on a graph:

<http://freethinker.co.uk/2009/09/25/8419/>

</comment><comment><USER11> In your life you have just 2 options, 1) Just belive in God and accept him as your savior, and understand that the other things in this world are secondary...or 2) belive in the idea that a big explosion of nothing in the middle of nothing creates everything around you. I selected option 1.

</comment><comment><USER12> I think this is an interesting question and is not off topic. I personally don't believe in god until proven wrong. i think the concept of believing in god is Ridicules it's no different then believing in unicorns.

</comment><comment><USER13> I believe in myself.

</comment><comment><USER14> This doesn't have much to do with hacking or entrepreneurship. I'm interested in the answer too, but lets not turn HN into reddit.

<comment><AUTHOR> Well, I was curious about the impact (if any) on entrepreneurship and/or hacking... Whether it inspires people or whether they find inspiration from elsewhere (Ubermensch anyone?)

That being said, this is definitely an almost-reddit question... And I apologize for that; I hesitated before posting it but figured I would anyway... I am a bastard.

</comment></comment><comment><USER15> Off topic.

Why does it matter what others believe? Blaze your own path.

<comment><USER3> Blaze your own path of belief without input from other smart people with interesting perspectives? That sounds like the opposite of a good idea (a bad idea)</comment></comment>


SecondMarket forming a syndicate to bid in US Marshals Bitcoin auction - <AUTHOR> https://bitco.wufoo.com/forms/participate-in-us-marshals-bitcoin-auction/

<comment><AUTHOR> Tweet announcing it

[https://twitter.com/barrysilbert/status/477931080889012224](https://twitter.com/barrysilbert/status/477931080889012224)</comment>


Ethical consumers are seen as unattractive and boring by others, study finds - <AUTHOR> http://www.theguardian.com/lifeandstyle/2016/apr/22/oliver-burkeman-change-life-ethical-consumers <comment><AUTHOR> This article made me wonder how this might translate into tech choices (rather than consuming choices).

We'd have to define what a moral tech choice is (a candidate would be "tech X is more efficient doing what it's supposed to do than tech Y"). Then the other variables could be the price/cost, the trendiness, the license, the backers, the market share, simplicity etc.

Now, are people making choices based on efficiency of the tech considered weirdos or dismissed by others whose choices are directed by other factors like trendiness or simplicity? And if so, is it just because they know that their choice is not the "moral" one?</comment>


Hackermoon: A visualization of the life of an entrepreneur - <AUTHOR> https://hackernoon.com/whats-the-point-of-being-an-entrepreneur-69bfb5f39483 <comment><AUTHOR> If you are coders, hackers or entrepreneurs I would love to hear what you think about this approach</comment>


Trump Administration Releases Transparency Rule in Hospital Pricing - <AUTHOR> https://www.wsj.com/articles/trump-administration-releases-transparency-rule-in-hospital-pricing-11573825649?mod=rsswn <comment><USER2> HHS Press release: [https://www.hhs.gov/about/news/2018/08/01/trump- administrati...](https://www.hhs.gov/about/news/2018/08/01/trump- administration-delivers-on-promise-of-more-affordable-health-insurance- options.html)

The rule: [https://s3.amazonaws.com/public- inspection.federalregister.g...](https://s3.amazonaws.com/public- inspection.federalregister.gov/2018-16568.pdf)

Giving the people more information is unambigiously a good thing.

[https://www.cnbc.com/2019/11/15/trump-releases-rule- requirin...](https://www.cnbc.com/2019/11/15/trump-releases-rule-requiring- hospitals-and-insurers-to-disclose-negotiated-rates.html)</comment>


JEP 325: Switch Expressions - <AUTHOR> http://openjdk.java.net/jeps/325 <comment><USER2> I must have gone full lisp weenie, because I find it ridiculous when remembering the days of being a happy java dev, waiting years for someone to include a syntactic change in the spec, all whilst crossing my fingers that they will include my use case.

Clojure macros have spoiled me with cond, condp and case plus whatever else I or the community come up with. And my half thought out changes are nicely isolated to a single project or library instead of baked into the language for eternity.

<comment><USER3> Generally speaking, when a language developer adds really useful, special syntax to a language — that language users cannot define themselves — it seems like a good idea to stop, and consider whether it makes sense to restrict the usefulness of this concept to just this special case.

I.e. the Java _boolean_ type, which can only be _true_ or _false_ (and not _default_ ). Could it be that there are other valuable uses of this ability, instead of using enums where you always have to handle the _default_ case?

Can it really be the case that _true_ / _false_ is the only case where not having to worry about _default_ is extremely helpful?

<comment><USER2> I'm sorry, but I'm a little confused by your comment about default cases in reply to mine about syntax extensions being in the hands of language designers vs everyone.

I am also a little unsure what you mean by not worrying about default. Even polymorphism has to deal with this, if you call a polymorphic method on an object that doesn't implement that interface you'll get at best a compile problem, at worst a cast exception. This is why some languages provide support for a "default" or "method not implemented" hook in polymorphism.

If you are arguing that polymorphism is a better way to build systems than switch/case statements then no argument here. Open constructs like polymorphism are far better for growing and evolving large systems over time.

That doesn't mean we should exclude a nice way to say "i've got a variable that i want to translate to some other value in a few different ways".

My point was only that it just seems so silly to me that everyone is discussing whether this syntax is "best" or how it "doesn't do X, Y or Z", because I remember doing that too before Rich Hickey (angelic choir noises) showed me that actually you don't have to put up with that shit. Just use a language that puts syntax extension in the hands of it's community and let them figure it out without burdening the core language with a thousand little tradeoffs for the 90% use case.

<comment><USER4> > Just use a language that puts syntax extension in the hands of it's > community and let them figure it out without burdening the core language > with a thousand little tradeoffs for the 90% use case.

The downside of that is that some Lisp projects can only be understood by the original authors, during the time they were actually active on it.

I have seen a few that went DSL crazy with macros.

Scalaz is another "good" example of that.

</comment></comment></comment></comment><comment><USER5> My view is that this shows again that worse is better. The old form is better because it is awkward and it can only be improved by turning it into a function.

Within a function, each switch branch can be a return. Then you get the benefits:

* Make the original function shorter.

* Give a descriptive name to what you're computing.

* Make the computation reusable.

It's what I find lacking with lambdas: it makes it too easy to forego good refactoring because it makes too easy to write one-off code that in reality will be rewritten many times in different places.

<comment><USER6> No, worse is worse. Pattern matching is much, much cleaner than a switch with the branches extracted in separate functions. I don't think that anyone using languages that support proper pattern matching can disagree.

If someone is writing the same lambda n times instead of extracting it in a common method the problem is not the lambda function, but the developer. Closures are probably the best feature in Java and they have been delayed enough.

<comment><USER7> > Pattern matching is much, much cleaner than a switch with the branches > extracted in separate functions

I don't think that's what is being suggested. I think the suggestion is to move the entire switch statement to a separate function, use 'return' in the switch cases, and have the caller assign the variable once, from the return value of the function.

</comment></comment></comment><comment><USER8> Interesting to see Java copy modern languages good ideas.

The footgun of 'break' in switch statements has always bothered me, I strongly prefer the kotlin/swift way of doing this.

<comment><USER9> How is "break" in switch statements a footgun in Java? It is annoying boilerplate to need a "break" after each case, but how can it lead to shooting yourself in the foot?

<comment><USER8> Because I have seen more than once devs forgetting to add a 'break;', resulting in more or less subtle bugs.

The kotlin/swift way of declaring this flow does not let you do this mistake.

<comment><USER10> I recommend using ErrorProne in Your projects. There are several problems its compiler will catch and fall through begin one of them: [http://errorprone.info/bugpattern/FallThrough](http://errorprone.info/bugpattern/FallThrough)

It might take quite a lot of work to fix (or bypass) all the reported problems in a large codebase but it is worth it.

</comment></comment></comment></comment><comment><USER11> [https://reasonml.github.io/](https://reasonml.github.io/) \- When '|' becomes a case.

[https://docs.scala-lang.org/tour/pattern-matching.html](https://docs.scala- lang.org/tour/pattern-matching.html)

[https://antonioleiva.com/when-expression- kotlin/](https://antonioleiva.com/when-expression-kotlin/)

[https://www.reddit.com/r/java/comments/7rgnei/jep_325_switch...](https://www.reddit.com/r/java/comments/7rgnei/jep_325_switch_expressions/)

</comment><comment><USER12> I'm seeing a lot of interest in pattern matching as users that have discovered it via rust's `match` or similar want to benefit from it in $dayjob language.

C# has seen a similar push to implement pattern matching, down to the use of `_` as discard. The first iteration of this feature in C# 7 is feature light, but it's a good start, and they've promised more to come. The team behind C# has become really good at getting over NIH and embracing new technologies and techniques while somehow preserving backwards compatibility and ergonomics. Anders Hejlsberg doesn't kid around.

Here's an example cribbed from an official MSFT blog [0]:

        public static int Count<T>(this IEnumerable<T> e)
        {
            switch (e)
            {
                case ICollection<T> c: return c.Count;
                case IReadOnlyCollection<T> c: return c.Count;
                // Matches concurrent collections
                case IProducerConsumerCollection<T> pc: return pc.Count;
                // Matches if e is not null
                case IEnumerable<T> _: return e.Count();
                // Default case is handled when e is null
                default: return 0;
            }
        }

A lot of people have lamented this as the death of F#, but I think MSFT is making the right calls here.

EDIT:

Little-known fact: C# actually _does_ have discriminated unions, and has had for a long time (from the start?) in the form of the `Exception` base class. In fact, pattern matching in C# can be "pulled off" (read: hacked together as a proof-of-concept) without the changes from C# 7 by simply using the extended catch syntax:

        class MyType1 : System.Exception
        { /* ... */ }

        class MyType2 : System.Exception
        { /* ... */ }

        void foo()
        {
            throw something ? new MyType1() : new MyType2();
        }

        void bar()
        {
            try
            {
                foo()
            }
            catch (MyType1 mtype)
            {
                //take type-specific action here
            }
            catch (MyType2 mtype)
            {
                //take type-specific action here
            }
            catch (Exception _)
            {
                //the _ was optional, but this is the `default` block
            }
        }

[0]: [https://blogs.msdn.microsoft.com/seteplia/2017/10/16/dissect...](https://blogs.msdn.microsoft.com/seteplia/2017/10/16/dissecting- the-pattern-matching-in-c-7/)

<comment><USER13> I might be wrong, but I'd say that the interest in switch expressions and pattern matching from the Java community most likely comes from Scala (a JVM language) rather than Rust. Here's an example from the Scala docs:

      def showNotification(notification: Notification): String = {
        notification match {
          case Email(email, title, _) =>
            s"You got an email from $email with title: $title"
          case SMS(number, message) =>
            s"You got an SMS from $number! Message: $message"
          case VoiceRecording(name, link) =>
            s"you received a Voice Recording from $name! Click the link to hear it: $link"
        }
    }

<comment><USER14> No need for the '{' after "String = ". It'll make your code less crowded.

</comment></comment></comment><comment><USER15> Doh, can't we have pattern matching - with destructuring of course - and be done with it?

(And tuples, ADTs ah the list goes on..)

<comment><USER16> There's a separate JEP [1] for pattern matching, and the switch expressions are both preparation, companion and requirement for it.

[1]: [http://openjdk.java.net/jeps/305](http://openjdk.java.net/jeps/305)

<comment><USER15> Nice, I don't see how I could – at the very least - upvote for this proposal. How does that work?

</comment></comment></comment><comment><USER17> Assignable return values: +1

Concise AND expressions (eg "case UP, DOWN -> 1;"): +1

Using keyword 'break' instead of 'return': -1

<comment><USER18> 'break' feels ugly, but doesn't 'return' already have a different meaning here?

You could do something context sensitive to make 'return' act differently in a switch expression versus a switch statement, but that seems more confusing.

<comment><USER19> > You could do something context sensitive to make 'return' act differently in > a switch expression versus a switch statement

But you _shouldn 't_. That would break existing code. What if you actually want to return something from within a switch statement?

<comment><USER18> You ignored the parts where I said "already has a different meaning" and "that seems more confusing".

</comment></comment></comment></comment><comment><USER20> Glad to see conditional expressions becoming popular. TBH it's hard for me to understand why anyone ever felt that switch/if should be statements. I guess being too immersed in assembly programming?

</comment><comment><USER21> I don't need this. In most cases everything can be solved with different methods overrided by type. This is OOP way.

But it's makes language more complicated and what is more important - it makes harder to refactor, especially via IDE. So my opinition: we don't need this and this doesn't have any value besides marketing.

<comment><USER22> The problem with OOP way is that it's overly wordy and complex in this case. Much like switch statements in procedural code before the advent of OOP.

Type-based function overloads are not specific to OOP, by the way.

</comment></comment><comment><USER23> This is inconsistent and no longer Java.

The -> is not a good idea and break <something> should be return <something>. The -> throw e; "sugar" is just ridiculous!

<comment><USER24> IMO, return <something> may be ambiguous in switch expression.

<comment><USER23> Yeah, but return gives the value of an expression and break is a control flow keyword.

</comment></comment></comment><comment><USER25> I want this in Go!

<comment><USER16> Don't count on it. Go decided against if-expressions despite them being much more common, so I don't see pattern-matching-like construction coming to go.

</comment></comment><comment><USER26> This looks like a backport of Kotlin's `when` expression.

<comment><USER16> Is that a bad thing?

Also it's much more similar to Scala's "match" expression, which is also on the JVM and predates Kotlin by about 7 years.

</comment></comment><comment><USER27> Languages shouldn't try so hard to wrap syntax around one _particular_ use for something, because you end up tearing the whole thing apart in maintenance. It's sort of optimizing the writing of the code, which isn't the worst part.

Here, "int result = switch..." seems nice for that one situation, "until it isn't" (and in my experience these "until" events can come as soon as the very next time you have to maintain the thing). Oh, wait: I actually want to log something in one of the cases in addition to the assignment but since the entire thing is a fancy assignment expression now I have to rewrite 90% of it to add a glorified print statement for one of them!?

And it's not just Java. In "new" C++ for instance, the highly-specialized syntax for loop iteration _is nice_ but it has the same problem: sometimes the change you're making _does need iterators_ , unusual increment points, etc. and you end up peeling apart everything that was supposed to be so helpful and rewriting way more than you should need to.

<comment><USER16> You're completely missing the point. The switch expression is exactly that, an expression. It can be used wherever you can use an expression. This is fundamental to programming languages and especially in functional programming languages where it is a requirement of everything in the language.

You can use logging/side effect in it. You can not assign it to a variable, all valid in Java.

Consider the if expression (ternary ?: operator in Java). In most modern languages (e.g. Scala, Kotlin, Rust) there is no ternary operator, and only an if-expression:

        int value = if(something) 1 else 2

According to you, this is wrong, but it isn't, you can still use it as a statement:

        if(something) {
           doThis()
        } else {
           doThat()
        }

Just like you can have a statement (line) with just "1+1" or "doThis()", you can have a statement of just an if-expression.

And you can also add side-effect (logging) withing expressions:

        int value = if(something) {
            log("Uh oh");
            -1
        } else {
            1
        }

Making a language construct an expression is the complete opposite of tying it to a particular use-case, it's giving it the ultimate flexibility because you can use expressions _everywhere_.

<comment><USER27> I'm not debating why expressions are part of languages. I'm saying that I shouldn't have to tear apart half the code just to make a change.

And there are very simple examples of that problem, right in the article:

1\. Allowing the entire switch expression to bind to the same assignment makes it difficult to maintain when adding a case that _will not_ perform that assignment. Now, instead of adding one line, you're tearing apart half the block and trying to find a way to make equivalent new code.

2\. Even adding a single line to a case may be impossible without rewriting the case. Given some 'case "Bar" -> 2;', the maintainer has to redo the entire thing: rewrite it as 'case "Bar":' with a colon, add 'break 2;' to preserve original behavior, and _then_ add their stuff. That's just broken; it won't even produce a clean "diff" because you're "changing" lines that don't have anything to do with your new code. And you can bet at some point that somebody may just plain forget to add back the "break" when rewriting the expression needlessly, introducing a bug.</comment></comment></comment>