Redis will remain BSD licensed | Hacker News Reader

Redis will remain BSD licensed

antirez.com

448 pointsantirez197 comments

Hi, this is Yiftach, CTO and Co-founder of Redis Labs. First, let me assure you that Redis remains and always will remain, open source, BSD license. For avoiding any doubt - commons clause (as defined in commonsclause.com) is applied only to add-ons (modules), on top of Redis (e.g. RediSearch, Redis Graph, ReJSON, Redis-ML, Rebloom) that were developed by Redis Labs .

We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, and (b) we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.

In addition, a few people here (and other threads) have asked why we didn’t create a new proprietary license, like those offered by Elastic or MaraiaDB? Well, Commons Clause was created by a coalition of several OSS infrastructure companies, some of which use a different OSS licenses. In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.

> we got requests from developers, working at large enterprises to move from AGPL to a more permissive license

...so you did exactly the opposite, though with naming that makes it sound like you honored that request until you actually read the license terms.

it's more permissive for some enterprise use cases if you're worried about AGPL consequences. You now can use it in internal systems. (Assuming you feel comfortable interpreting the vague bits of the "Commons Clause")

Yeah the commons clause does not seem like a very well written license. They even mix up i.e. and e.g.

Not confidence-inspiring.

First of all, I do appreciate your reply here.

> we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.

It's not clear how Commons Clause will help here. I can't imagine many corporations liking Commons Clause if they have decided against AGPL.

Well, we already have positive responses from few large enterprises.

I think that what happens here is that enterprises don't like a license where there is this concept of open sourcing internal changes. They are happier with limiting the kind of use you can do with the code instead, like doing SaaS, that most of them don't plan to do at all.

AGPL doesn't require releasing internal changes unless the changed code is served (like in SaaS) externally. Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.

Im generally curious, what's the definition of "externally"? It's a bit more vague compared to "operating as a service", since you may expose your service externally, but only allow access to internal users.

The license itself doesn't treat "externally" different from "internally". Its terms are simple: any one who uses it should have a way to get the source.

If you let someone "external" to the company use the software over a network, then, during their use, they should have a way to get the source. If you don't let any one "external" connect to the service, then there's no need for you to provide them a way to get the source.

-----

For example, if there were a software like redis, but one that were licensed under the GNU AGPLv3 — say 'gredis' — and you let someone connect to it — say, using 'gredis-cli' — then you must make the source available to them. But if you run this 'gredis' software in your stack and make use of it in your stack but don't let anyone except your ops team connect to the running 'gredis' instances, then you need make your source available only to your ops team.

I don't know about GNU, but OpenStreetMap has a licence where bits kick in if it's used externally, and it defines it as:

"“Publicly” – means to Persons other than You or under Your control by either more than 50% ownership or by the power to direct their activities (such as contracting with an independent consultant)."

So if you can tell someone to do something, they are internal. If you can't, then that's public.

https://opendatacommons.org/licenses/odbl/1.0/

Here is the actual portion of the GNU AGPLv3 that is relevant:

> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.

There are a few key things to note (I'm not a lawyer, but the idea of the GPL family of licenses is that they be written so that developers can also understand them):

* It only applies to people who have modified their version of the software, so if you just run code provided to you by someone else you don't need to give network users the source code.

* It uses the term "users" which would imply that if you state that someone external to your company is not permitted to use the service, they would not be considered a user (and thus you don't need to give them a copy of the source).

> Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.

I'm not so sure about that. If it is only on an internal network, where everyone who uses it is using it in their capacity as employees of the organization, would the source code obligation apply to them personally, or would it apply to the company because they are acting as agents of the company? If the later, the obligation would be for the company to provide itself a copy of the code.

The license doesn't distinguish people from people working as employees. The original AGPL (not GNU) states[1], in its FAQ:

"Simply, if run internally to a commercial company, then the company isn't required to release source code back to the world."; and

"If an employee has access to the source and has the right to make improvements, the commercial entity could probably view this work as work for hire and owned by the company and not have to be released outside."

1: http://www.affero.org/oagf.html#How_does_this_license_treat_...

Thank you for the explanation. I see no problem with this approach in principle and wish your business the best of luck.

However, you have made a big mistake with how the "Commons Clause" confuses Open Source under the OSD with "source available". You were not well served by those who advised you to do so.

The Commons Clause clearly acknowledges this in the FAQ:

https://commonsclause.com/

From that page:

> The Commons Clause is a license condition drafted by Heather Meeker that applies a minimal-form commercial restriction on top of an existing open source license

Making it proprietary and failing the Open Source Definition.

You cannot have Commons Clause 'on top' of an existing Open Source license. This is impossible. You can only replace the existing Open Source license with Commons Clause.

The page is a bunch of (insert HN-guidelines-appropriate word for 'very incorrect information').

> This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements.

Commercial and Open Source aren't opposites - this a very basic mistake made by people who are new to OSS. There are many Open Source commercial projects (your bank runs on Red Hat Linux, which is entirely OSS, with everything but the Red Hat logos allowed to be reproduced) and many non-commercial proprietary projects. It's scary that a company called 'Fossa' whose specialty is 'Modern open source management_' is confused about this.

> The original Open Source Definition represents an immensely important set of ideals that carried many projects to success during the earlier days. However, the open source ecosystem has changed a lot over the past 10 years, and the conditions of the modern landscape has forced change for the sustainability of many projects.

The project wants to create a new OSD which isn't Open Source.

The 'drafter' of this license seems to have simply re-created Shared Source per Ballmer-era Microsoft.

Yes, and right below it acknowledges that it is not Open Source and doesn't try to be:

> It this “Open Source”? > No, at least not by the official definition set forth by the OSD. Applying the Clause to an open source project will transition the project to “source-available”.

Yes. The page is full of tautologies. It shoudn't be.

Here's a pull request: https://github.com/fossas/commons-clause/pull/3

> Is this Open Source? No. The source is available for inspection and restricted use but, because of these restrictions, its licence is not Open Source per the Open Source Definition.

That's all that needs to be said. Your page reads as though the author is hiding something or that the author is ashamed of the answer. Just come out and say it.

There's no need to get personal about it, even when you disagree about licensing. Please don't.

The "what's the clause?" section starts with a plug for the clause's creator - even before answering the question, which seems a bit unnecessary, but I'll edit the post and remove the personal reference. Sorry Dan.

Simply naming someone is not 'a plug'. It's just naming someone.

This response, created by nailer on Hacker News, illustrates the awkwardness of mentioning the credit before the content.

It doesn't really, or if it does, it demonstrates awkwardness, not endorsement or a plug. Beside that, they they posted the faq just as DannyBee started asking them questions here:

https://news.ycombinator.com/item?id=17815389

and specifically asked them who drafted the thing, among other things.

Then they should answer that in 'who drafted Commons Clause?' not 'What is Commons Clause?' before they've answered what Commons Clause is.

Appreciated!

Replying to myself here as I think I got this part wrong:

This isn't actually making the 'commercial vs open source' mistake, it seems to mean:

> This Clause is not intended to be applied against all open source projects, but incrementally on top of commercial software that is currently open source but needs to be transitioned away from open source to to source-availability to satisfy urgent business or legal requirements.

That's what I've put in the PR anyway.

The FAQ is not a sufficient corrective for all the deceptive top-level messaging around "Commons Clause". (Name, abbreviation, suggested usage all inappropriately invoking open source).

Worse, none of the deceptiveness was necessary to implement the plan described by the Redis Labs Co-Founder above, which is completely [edit: potentially] compatible with Open Source. Antagonizing the wider Open Source community was pointless.

That FAQ was quickly added after the yelling started. It's the weaseling and obfuscating that in the end look a lot worse than the perfectly sensible desire to make more money from your products. They could have achieved that without the bizarre 'piss down your back and tell you it's raining' approach.

That's irrelevant. Nobody is going to read your FAQ. You intentionally created something that tries to muddy the lines between Open Source and Non Open Source. It's dishonest, and deceitful.

You can't abuse anyone like that here regardless of how wrong they are or how you feel they are. Please keep the online shaming culture well away from HN.

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

You're right, and I've edited my post to reflect that.

Commons Clause software isn't just "source available"; you can modify it and redistribute it, such that the regular FOSS workflow of "fork on GitHub and create a PR" is legal.

You just can't deploy your fork (or the original code) in a private service without paying for a license for that code.

The content of the license is not what is causing the huge negative reaction -- it's the deceptive messaging.

Redis Labs has the opportunity to largely erase this blunder by ditching the name "Commons Clause" and offering the same terms under honest labeling.

This is the top post in the thread from ~18 hours ago:

https://news.ycombinator.com/item?id=17816332

Everybody wants to have their word in how that software they didn't write should be licensed. The back and forth ends up being something akin to "It's your own fault for picking BSD; you shouldn't have picked that in the first place!... now why don't you make all the other stuff BSD too?".

Frankly, I don't see what the OSD/OSI definition of open source matters. You pick the license that suits your needs best. People ought to argue the license on its actual text and merits, not whether some other organization likes it or not, otherwise it's just argumentation by authority.

BTW, you should probably change https://redislabs.com/community/oss-projects/ to match the the non-Open-Source-licenses most things have there. (yes, they are listed, but the page pretends everything on it is Open Source)

You're mixing up Open Source and Free Software, those two are not the same.

They have different ideologies behind them, but they refer to almost exactly the same class of software. A license that doesn't allow commercial use is proprietary and closed source.

Forbidding commercial use doesn't make something closed source but it does make it proprietary. The compliment of Open Source isn't closed source.

Can you give an example of something that's neither open source nor closed source, or of something that's both open source and closed source?

Gitlab EE is one.

Not closed source since the source is public and freely given [1]. Not open source because the license [2] forbids use based on field of endeavor which is required in the OSD [3].

[1] https://gitlab.com/gitlab-org/gitlab-ee [2] https://gitlab.com/gitlab-org/gitlab-ee/blob/master/LICENSE [3] https://opensource.org/osd-annotated

Not that Wikipedia is a source of truth but it does corroborate that at least some other people agree with this analysis [4].

[4] https://simple.wikipedia.org/wiki/Closed_source

Edit:

As for the other direction, you can't have software be Open Source and closed source simultaneously since being Open Source requires the source to be available. Or in symbols.

Free Software ⊆ Open Source ⊆ source-available

closed source ∪ source-available = 𝕌

closed source ∩ source-available = ∅

Commons Clause is neither open source nor closed source; it is proprietary. Something cannot be both open source and closed source.

Open Source software can be proprietary, see all the github repos without license information.

What you are referring to is "Free Software", as defined by Stallman.

According to most of people who invented the term "open source", the OSI and their open source definition, propritary software, even if you can see the source, is not "open source".

Nearly everyone uses the term "open source" this way, and to use it otherwise is grossly misleading.

Of course, if you follow the osi definition you are absolutely correct. [1]

"the obvious meaning for the expression “open source software”—and the one most people seem to think it means—is “You can look at the source code.”" [2]

The main problem imho lies in the fact that afaik we still don't know how to call proprietary software with released source code, although this is mighty common (again, see github). If that problem is solved, the osi definition is much better applicable.

(On a side note: A word that might describe such software is public. Public Software vs. Open Software Software. This however is again problematic because of "public-domain" software.)

[1] https://opensource.org/osd

[2] https://www.gnu.org/philosophy/open-source-misses-the-point....

> the obvious meaning for the expression “open source software”—and the one most people seem to think it means

I disagree. I think if you ask nearly people who know what the term "source code" means, if you ask them what "open source" means, they'll give the OSI definition (which is in practice the same as the FSF's 'free software' definition). They'll say it's more than "I can look at the source", but includes the rights to share and build on it.

Microsoft tried the term "Shared Source", which might be what you mean.

There is a difference between Open Source and merely making the source code available. See the definition here: https://opensource.org/osd

In particular, this comes into conflict with 1, Free Redistribution.

It doesn't. Anyone is able to redistribute these Redis Modules under the same license.

Here is the Free Redistribution section: "The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources."

Yiftech commented that the reason for making the switch was that "AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules". The entire reason for making the switch to licensing the modules under the new license is that the Free Redistribution aspect of AGPL and other open source licenses allows cloud providers to use the software in a way that Redis labs doesn't like.

Cloud providers are not "giving away or selling" the software, they are running it, which isn't covered under that section.

You're probably looking for #6:

> 6. No Discrimination Against Fields of Endeavor

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. ... or in this case, "offering Redis with extension X as a Service"

> You're mixing up Open Source and Free Software, those two are not the same.

There is an ideological difference between the movements, but very little practical definitions between the OSI Open Source definition and the FSF Free Software definition. Yes, they are worded differently, but in practice they are virtually identical (I don't think a single license has been reviewed by both entities with a different conclusion.)

> because the use of AGPL is against their company’s policy.

Have you confirmed with these same people that the new license is allowed by their company policies?

Believe it or not - the answer is 'yes'

I don't think this is strange at all btw, https://news.ycombinator.com/item?id=17819769

Hmmm, I wonder if you could use a license even more virulent than the AGPL to approach problem (a) and then dual license to solve (b)

>from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.

But to effect, it is the same. The point of them restricting use of AGPL is them not wanting to publish the code while making money of it. To the effect, they still can't make money of it.

In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.

And that was a bad decision and it needs to be reverted. What you're doing is dishonest, point blank.

If you don't want to write a new license from scratch, take one of the ones off this list, and fork it and make a "Redis Non-Commercial License" or whatever you want to call it.

https://en.wikipedia.org/wiki/Source-available_software#Rest...

Yiftach (and Antirez),

Please talk more about AGPL. MongoDB has a similar problem, and they solved it by making their product dual-licensed, AGPL + commercial. They then clarified the AGPL to say that in their opinion, it did in fact prevent cloud providers from building managed services around the modules.

https://www.mongodb.com/community/licensing/faq

The AGPL is lengthy and a bit convoluted, so it's possible they're wrong. Could you talk through your reasoning?

Well - I can only say that what MongoDB has is not complete. There are still many holes, and we prefer to avoid them. And of course this doesn't solve the other issue, where developers cannot use AGPL in large enterprises.

The actual wording of the Commons Clause is very general and ambiguous. I'd be surprised if this didn't continue to cause issues within large enterprises.

Couldn't you sell them the commercially licensed version then, if you had the AGPL + commercial dual license?

But that's kind of the point -- those who live in large enterprises who can't use the AGPL must buy a commercial license. The AGPL is toxic in some places, and its use is a deliberate attempt to nudge people toward a commercial license. Did this not work in your case?

> where developers cannot use AGPL in large enterprises

developers who cannot use AGPL in large enterprises are probably forbidden to use non-open-source software distributed under a shared-source license that allows no commercial use.

A non-charitable reading would be "we want mindshare and adoption from developers in large enterprises who will then buy or software rather than admit that they were unable to understand our terms and assumed our software was liberal open source".

To make things more concrete - while GPL allows unrestricted internal use, the horror scenario would be the contractor who is brought in to work on software including GPLd code and who may have right to receiving the source of everything (as a "derived work"). How is CommonsClause-licensed shared source dealing with large enterprises employing contractors for working with their software? Is the contractor in breach of CommonsClause but the large enterprise isn't?

>There are still many holes

As somebody who licenses software as AGPL, could you please list those?

I'm not speaking on anyone's behalf but MongoDB's interpretation of AGPL is very contentious and extreme.

"commons clause (as defined in commonsclause.com) "

That is subject to change so without a specific version number / date it is effectively useless as a guide.

We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules,

Aren't there good solutions within open source licenses? I agree that the AGPL does not solve the stated issue. However, the Apache License version 2.0 has the following text:

If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. [...]

I typically use the Apache License version 2 and include a NOTICE file with something like

This software contains portions of XYZ, which was developed by Daniël de Kok.

I do get contacted every once in a while by a company that wants to use my software, but does not want to include this notice in their software/documentation and offer to pay to remove the notice. You could even make it a bit nefarious like:

This software uses XYZ, but your software/service vendor is a cheapskate that leaches off XYZ and kills puppies by not contributing back to XYZ.

And offer the option to obtain a (proprietary) license that allows use with removal of the notice. IANAL, and I don't know if the Apache License's NOTICE wording also covers use in cloud services (it seems so). If not, it would be an easy extension. And the outcome is much better than the abomination that Commons Clause is: the software stays open source and it puts pressure on downstream users to contribute back.

> AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules

I'm not sure I understand this formulation. The * gp licenses are generally focused on defending the four freedoms[f] - and freedom zero is the freedom to run the software. How would anyone think that a * gp license would prevent that?

Am I correct in my interpretation that Redis Labs' original intention was to charge a fee for these modules, and in the case of various form of re-sales (like SaaS) - to partner with providers so that there was a revenue split?

I'm asking, not because I'm against commercial software (although I do prefer to run Free software) - but just to make sure I understand the [ed:"drawbacks"] of the AGPL as Redis Labs sees it?

[f] https://www.gnu.org/philosophy/free-sw.en.html

GNU licenses require sharing code. Bad for business.

For GPL (not talking AGPL as my knowledge there is too limited) Vendors in "classical" environments GPL is a valid business choice - competitors get access to the code, but also have to share their extensions. The original vendor however can be in a stronger position and share their extensions commercially (with dual licensing and CLAs for external contributions) In a cloud environment however the cloud vendor doesn't "redistribute" the software, thus doesn't have to share their extensions, thus taking revenues without any contributions, putting the cloud vendor in an even better position as the original vendor, as the original vendor pays for the maintenance of the core product, which the cloud vendor uses for free.

And the main trust of the AGPL is treating giving access to a running program, as traditional GPL "distribution" - code must be made available to users of a service upon request - along with any changes.

With GPL - for example - Amazon could freely customize the Linux kernel with a new software defined networking stack for use by s3 back-end services. And would be free not to share the changes. If the kernel was under AGPL users of s3 would have a legal right to see the changes.

Of the Linux kernel was under AGPL, they would probably just use some other code under less restrictive license instead.

It was just an example. Fwiw netflix uses a bit of freebsd - but I also believe they contribute back to the community.

"...a few people here (and other threads) have asked why we didn't create a new proprietary license..."

But, you did create a new proprietary license. That's what ${ANY_OPEN_SOURCE_LICENSE} + COMMONS_CLAUSE is.

All this is is a proprietary fork of Redis. It's no different than if someone else -- someone other than Redis Labs -- had done it. What's unusual here is just the reluctance on Redis Labs' part to call it what it is. I think a lot of the surprise and blowback across the Net is simply because of the strange unwillingness on Redis Labs' part to call this by its right name and own it.

I'm not sure I follow here...

a) Is there an example of a cloud provider adopting or building on top of your existing AGPL code bases? The big 3 all have fairly well known internal policies that forbid AGPL use. Ever wonder why there isn't there a MongoDB service being offered by any of the major cloud providers? AGPL.

All that being said I doubt they would want your modules anyways. Their track record tends to be:

* AWS would grab the core BSD licensed project, ignore your management tooling regardless of license, and build their own management tooling that integrates with their ecosystem. Theres a few exceptions to this like [Chef and AWS on OpsWorks](https://twitter.com/adamhjk/status/1032312528196575234).

* Google. They wont use your software either. If anything they'll build some wizbang redis like protocol and interface on one of their internal proprietary databases. All the software will work the same, but it'll be "better" because its powered by BigTable/Spanner/whatever.

* Microsoft. 50/50 shot they might actually just license your code and partner if they thought customers wanted it.

b) I'm not surprised that large customers aren't AGPL fans. Isn't this where they should come in with a dual-license approach and sell commercial licenses to the software you develop? So whats the win here?

This could have been made clear in a few simple sentences:

We have created a new software license which we are calling the 'Redis Labs License' (RLL), by adding the Commons Clause terms as extra restrictions on top of the Apache 2.0 License. We recognise this will no longer be a true Open Source license, but we consider it a fair trade-off between our business needs and our responsibility and commitment to the Redis community.

From now and in the future, work on the following Redis Labs modules will be published under the RLL: Module A, Module B and Module C.

There will be no change to the licensing of Redis core, and we remain committed to supporting ongoing development under the existing BSD license.

Redis went out of their way to obfuscate what they were doing with deceptive license names. Now they are struggling to control the damage caused in all the confusion. There's a lesson here...

> Redis

Redis Labs isn't Redis, any more than, say, Heroku is Ruby because Matz works there.

I’m happy to hear that Redis will remain BSD, but it’s a bit weird to play the “fake news” card. Can you really blame people for interpreting this the wrong way?

Especially when the original announcement was specifically targeting cloud providers, who, afaik, are just running vanilla redis.

If there is anything that we can learn from this, is that a little bit of forethought when putting these announcements out there is required, and blaming this on the readers is not fair.

The parts that I noticed were missing from the original announcement include more specifics about the parts of the system that would change licence and also whether the intention was to charge people to use these new parts. It was unclear whether the intention was to stop these cloud providers or to make them pay in some way for what they were doing.

Yep, now finally this is updated to specify exactly what changes license. Incidentally: nothing I ever worked to directly. It would be way cooler if also things like RediSearch or RediGraph could still be totally open source, but it's apparently very hard, Common Clause at least will allow it to be free-as-beer and with the source code available.

> Common Clause at least will allow it to be free-as-beer and with the source code available.

The license is very vague. According to this

> a product or service whose value derives, entirely or substantially, from the functionality of the Software.

What if I have big online shop with huge catalog and my software value "derives from the functionality of RedisSearch"? Do my only option not to host it at Redis Labs?

> my software value "derives from the functionality of RedisSearch"

Your software might just literally be 99% RedisSearch, but you're not making money from your software (e.g. by selling it); you're making money from operating your software, combined with content (e.g. by using it to facilitate e-commerce transactions.)

You'd be in trouble if you wanted to white-label "your technology" and sell it as a platform for other people to run their own online shops on, because it's not really "your technology" to sell.

But if your play isn't specifically that, then you're fine.

Also,

> Do my only option not to host it at Redis Labs?

this wouldn't be an option. The whole point of this license is that the software "RedisSearch" is owned by Redis Labs. Hosting it with Redis Labs themselves, or not, is irrelevant. You have to license the software (if you're deploying it yourself)—or rely on your DBaaS provider to license it for you (if they're deploying it.)

Basically exactly like a software patent, come to think of it.

I don't think he's blaming people, but it does seem odd if he had no input at all into the Redis Labs announcement.

Honestly my colleagues did a poor job with such an announcement there, and I did not get a chance to read it (which is actually a good thing, it means that the OSS division, I'm part of, is independent and can work to the Github repositories without caring about what the commercial side does). But it was kinda of a manifest to announce that certain things made inside Redis Labs are now Common Clause licensed. In doubt, why not asking? Also people that follow me and Redis for years getting trapped into this idea is very strange, I would never do that and without explaining, prior notice, and so forth. So yep the Common Clause page at Redis Labs sucked but in doubt ask instead of creating news out of no actual information.

The abbreviation "CC" will be confusing if Commons Clause got popular… We already have Creative Commons licenses.

Agreed, fixed.

Utterly confused. Does this have anything to do with Creative Commons licences? That's what the articles calls it in its first and last sentences.

Particularly because the linked post calls it "Creative Common" twice and "Common Clause" elsewhere.

When I see CC, I also tend to think it means Common Criteria :

https://en.m.wikipedia.org/wiki/Common_Criteria

It was clear to me from a careful reading that the page did not refer to Redis, but it also seemed deliberately designed to suggest that it did. It seemed pretty scummy.

And the name itself of "Commons Clause" is practically a tiny version of fake news, since it tries to give an "open source" feeling to what is essentially a proprietary license.

As a practical/PR matter, I think Redis Labs have likely shot themselves in the foot. I've been in a low-key debate advocating for Redis Labs over AWS elasticache on an upcoming project; my argument probably just got about 1000% harder, given the anti-RL sentiment I saw on our Slack last night.

(Finally, if you'll forgive me a bit of personal advice, I think for better or worse Redis + your personal brand + RedisLabs are now all somewhat tied together -- I'm not sure how much sense it makes for you to just pay attention to the OSS side of the house...)

I'll pile on here as well, we were thinking about shifting from elasticache to RL, but this has made that decision super easy.

Elasticache is a totally closed source implementation that does not contribute back to the community. How did this situation change your decision?

what would they contribute back? elasticache is just vanilla redis. aws is selling you compute time and ram.

> elasticache is just vanilla redis

Only at the interface level. Elasticache is a heavily forked Redis. There's a reason it's several versions behind.

that makes sense. i guess i had just assumed it was laziness. :-)

out of curiosity, do you have any idea what their mods might be?

I never bothered to really look into it -- I suspect it's semi-public information. If I had to guess, lots of internal changes to make Redis behave better in AWS's architecture to do with containerization, EC2, S3/EBS, maintenance automation related stuff, instrumentation, etc.

Oh actually definitely some stuff related to their redis clustering system.

They also support encryption in transit. That part was open sourced recently, but hasn't made it into upstream yet (though it most likely will from sounds of it).

Ironically AWS (and probably Google) is the reason why they had to adopt that kind of license since they are not giving back. Obviously AWS is not tied by the license but it would make sense for them to sponsor the product instead of milking it entirely. Elastic is having similar issues with AWS.

I'll second that the reputations are entwined at this point. My fear is that the "killer" new features will be implemented as RL source-available addons, to differentiate RL from AWS/Cloud providers.

I totally get why, as long as I can compile the addons and run on a server myself I'll be pretty happy.

> that the page did not refer to Redis, but it also seemed deliberately designed to suggest that it did

The thing that's going on here isn't that the page wants you to believe that the thing that changed license is Redis; the page (and Redis Labs' site in general) wants you to believe that they own Redis in some sense.

Redis Labs is essentially doing the same type of thing for Redis that e.g. RedHat or IBM does for OpenStack. They take this FOSS project, add their own secret sauce to it, brand the combined thing as "[our company] [FOSS project name]", and then try as hard as possible to conflate the "[our company] [FOSS project name]" distribution with the FOSS project itself. Because they want you to associate the brand-cachet of the FOSS project with their distribution.

That backfired in this specific instance, because people misinterpreted what Redis Labs was saying regarding "Redis Labs Redis" as applying to "Redis." But it's their whole business strategy, so they can't exactly stop.

If the commercial side can change the license without your knowledge then it is not a good thing at all.

I agree with your complaint but I wouldn't use the terminology "fake news". To me, that's more of a specific term that refers to media bias as a propaganda tool. Whereas this is more of a rumor mill going wild as rumor mills naturally tend to do.

But yes, while hoards of people behave in a bit of a crazy manner, it is a known thing, and if you're responsible for public communication, you should understand those quirks and their predictable consequences. And you should realize that an ounce of prevention is worth a pound of cure by just making everything as clear as possible from the beginning.

To be precise, the term 'fake news' is an accusation against the media, used as a propaganda tactic, and most often false.

What I find interesting is all of the comments saying

   "Well, I was going to use RedisLabs.. but because of this, i'll use AWS/elasticache"

Which is just such a weird statement. So instead of supporting the OSS creators and main contributors, who want a way to monetize their "value add" modules, while still giving the core software freely; you rather support a huge corporation that gives almost zero back to OSS ( AWS has a history of extend and embrace, make it a service/black box, with open source, that would make Microsoft of the 90s/00s proud!)

“...gives almost zero back to OSS...” This is not true as Amazon not only releases it’s own projects but contributes really broadly [0].

I can’t speak for others, but I understand the decision to choose ElastiCache over CC software as I understand Amazon’s model a lot better than projects that change their license.

So if I’m going to hinge on something non-OSS, I prefer the logical points where a utility that sells cloud compute so doesn’t care about software than for software companies that change their license, really substantially.

My org allows AGPL as we can easily comply. But we can’t comply with CC. This shift is a big deal and kind of hoses me.

You mention Microsoft in the 90s. They shared source code all the time, but you couldn’t use it and there was zero community. So if you want that, CC is way more likely to get us there as community contributions will dry up. I’d rather depend on companies that are explicit (ie, “this is open source, this is not”).

[0] https://aws.amazon.com/opensource/

> But we can’t comply with CC.

Why not? The point of the CC is literally "pay us to use it commercially." You can't just... pay them to use it? Even when that's exactly what you'd be doing by using an AWS service?

You could offer to pay them today, yes. And get a license. But is your license that handles your use case today still going to be valid and useful a year from now? Five years from now? What if redislabs decides there are some more loopholes in need of closing?

I'm not a fan of the AGPL. I think it's problematic as an example of copyright maximalism, and I think it's counterproductive in that it basically took a bunch of ideas that used to be FUD and said "yeah, what if we actually did that". But I can say this for it: you know what you're getting and you know that for all the burdens it puts on you, it (like the GNU GPL) was designed to make sure certain rugs can never be yanked out from under you.

Part of CC is that it’s unclear how it operates with the myriad of other project licenses we use.

But the main issue is that we contribute back to projects, even as minor patches or fixes. Contributing source to a proprietary, commercial code base has legal issues of nonpaid work and contribution.

And finally, “pay them to use it” is very ambiguous. How much to pay them? Is it the same amount today as tomorrow? I pay for support for substantial projects like RedHat, but is support included in licensing CC?

These questions are ambiguous. Perhaps in time they will get easier to answer. But this is exactly why I would rather use AWS with its “so clear its confusing” pricing [0] where I know exactly what I’m getting.

[0] https://aws.amazon.com/elasticache/pricing/

I don't think that's the problem. Real Open Source (at least for me) means that you can trust that's there's an unbiased commitment to make solutions widely available and implementable. It also means that you can switch between managed providers and/or between OS implementations and expect to have a similar experience.

There are so many ways to make money out of open source that are totally compatible with this approach. I don't see how keeping an iron grip on open source software (just because you're afraid that other people would make money out of it or whatever) would help you at all to monetize your own value-adds.

One reason from a corporate standpoint is dependency. You can assume AWS will continue to host the core Redis indefinitely, but if you use Redis Labs and your developers begin to use any of the the new proprietary modules, you are locked into the RL platform only. No other platform will be able to use those modules, the only option being rolling your own.

If RL quadruples their pricing, you'll just have to bear it. Definitely makes it more risky than it was.

But can’t AWS pay RedisLabs for those modules? That’s exactly what RL are after - a cut from the big hosting providers. If the demand is there (for the modules) then you’ll be able to license them via AWS.

> However in the fake news era my attempts to provide the correct information failed

Eww. This actually removes credibility from the announcement, given the way the term "fake news" continues to be used to distract from objective truth.

I think antirez is using it in the context of people misinterpreting some facts, followed by this misinterpretation escalating fast as a lot of people seem to think its the truth.

Here's an example of a high-profile one:

https://twitter.com/antirez/status/1032271799529218048

What I mean is that even after the project leader tells you it was just some confusion, the Github project still is marked as BSD, and nothing is written in the original announcement clearly stating that Redis would switch license, it is a bit strange that the information continues to spread regardless of what I continued to say.

I understand both your meaning and frustration. But I think acjohnson55's point is that the phrase "fake news" has become a loaded term. I avoid it because it may imply things I don't want to.

"Redis is an example of this paradigm. 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"

Crying fake news (which has been co-opted to mean "real news that I don't like or that you shouldn't pay attention to") completely undermined your statement. Yes, the original announcement wasn't just unclear, it is very clearly drawing a line that "this must be changed".

I admit that the communication was not great, but the announcement never said Redis would switch. Maybe I'm a bit biased, because before Redis Labs doing this license switch, we internally even agreed about taking the core BSD, so the goals of the company were always clear, regardless of the fact that this page in the company web site was unclear. But "Redis switching license" was factually incorrect since the start and never stated anywhere.

> but the announcement never said Redis would switch

> Redis’ permissive BSD open source license allows them to do so legally, but this must be changed

https://redislabs.com/community/commons-clause/

It sounds a bit different when not taken out of context:

> Redis is an example of this paradigm. 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. Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts. 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.

But Redislabs extensions were AGPL, not BSD beforehand.

Yeah, there is literally no way to read that except as a statement of intent to move BSD-licensed Redis into Common Clause, even if that wasn't the first step taken.

While this is being portrayed as a communication error, that strains belief—it sounds a lot more like an after-the-fact effort to deal with massive blowback at the very clearly stated intent.

I understand what you mean. I think you called it "fake news" because you were frustrated about reporters/bloggers/twitter personalities spreading a story without bothering to do any research to see if it's true (because the story is dramatic and easy to spread). The reason people are having issues with you using that term is it has developed a strong association with state-sponsored propaganda campaigns (see: Russia during 2016 election) rather than just lazy, half-assed "journalism", which is what this was. Both of these are real problems, but I wouldn't call the latter "fake news" because it wasn't manufactured by a party intending to harm you. It was just journalists being lazy.

"Redis’ permissive BSD open source license allows them to do so legally, but this must be changed" (extensions are AGPL, so this can only refer to Redis core)

But yeah, blame lazy journalists.

> Crying fake news (which has been co-opted to mean "real news that I don't like or that you shouldn't pay attention to") completely undermined your statement.

You realize that antirez (Salvatore Sanfilippo) lives in Italy, speaks English as a second language, and isn't exposed to the US political climate, right? Crucifying him for the US-coloquial subtextual connotation of his word choice is pretty uncharitable.

Being charitable to the speaker isn't beneficial when a very large contingent of readers were coming away with the wrong impression. Hence why they changed the wording.

It remains that the official statement from the company has incredibly misleading wording, so it seems suspect to attack people who might "misinterpret" that, though. Uncharitable, even.

I understand your meaning. The problem is that the phrase "fake news" in the United States at least is associated with a specific political party. Your message will be less well-received by part of your audience as a result. Perhaps you are fine with that, though.

EDIT: antirez updated the post, so this is no longer relevant.

There are two usages for the term "fake news".

The original one was news that's completely made up without reference facts. This term was created to describe sites that generate fictional news stories to support an agenda or get clicks.

The second one is news that is negative about you. This usage was created as a deflection from the actual problem of fiction being sold as fact, and has become the primary usage. It is an attack on news not for whether it's correct, but for how it makes you look.

Neither of these apply to an honest miscommunication, and they both describe the people who misunderstood the announcement as malicious enemies rather than the concerned fans of Redis they more likely are.

If you want to ship enterprise modules under a source-is-publicly-available-but-not-open-source license, a sort of limited-commercial-use-source-available-freeware license, I think that is definitely better in some ways than keeping them fully closed source, so should be applauded.

But, I think this "Commons Clause" condition was a poor choice of a way of achieving that end. Having some condition which is added to an existing open source license, and takes away some of the rights that license grants, is horribly confusing. If you aren't granting the full set of rights associated with open source license X, then open source license X should not even be mentioned.

If you had just picked some existing license which had the set of permissions you wanted, or even created a new one, I don't think anywhere near as many people would be complaining. "Commons Clause" is a horrible idea and should be retired.

But it does appear to be true that some Redis modules used to be open source software (OSS) and are now proprietary. As I understand it, some modules used to be licensed under the AGPL (an OSS license) and they are now under this new "Commons Clause" (which is a proprietary license). So while the core of Redis is OSS, if my understanding is correct, it's absolutely true that parts of Redis have switched to being proprietary software. That's different than organizations who license the software as "AGPL or proprietary" or "GPL or proprietary" - such licenses are also unambiguously OSS. Choosing "Apache WITH proprietary-rider" is fundamentally different; Redis has every right to do that, but it's fair to note that this isn't the same thing.

Also: there is no longer a source-disclosure requirement built into the license.

I've seen saying for years and years that we're going to see a resurgence of proprietary software. Free software was one of those ideas that spread so successfully that people temporarily forgot that life could be otherwise, which means they stopped caring about the idea, which in turn led to a complacency that, at first, shifted software licensing to a BSD-style permissive model, and now, is starting to allow 1990s cancer like this commonscause.com license restriction to come back.

There's nothing new in the software ecosystem driving this.

Well, this commonsclause.com crap is such a move toward proprietary software. We're here.

> The Commons Clause is a first step at starting an important discussion

The baseline is pretty high to call anything a resurgence.

I guess by revenue dollar most software is already proprietary, it's just billed as a service or whatnot.

Considering all the code inside of companies, it's probably the case that most lines of code are also proprietary.

Revenue is probably not a good measure, as an open source solution tends to reduce market size as measured by dollars spent. From Bob Young, founder of Red Hat:

> The reality is most of our users don’t pay us squat [...] Our business model [showed] that if we had millions of users, we only needed one-tenth of our users to actually find something of value to pay Red Hat for.

> If Microsoft’s earning $40 billion worth of operating system sales, and if we [reduce that to] a $4 billion-a-year market, because nine out of ten of the people that use our operating system aren’t going to pay us, we’re quite happy with a share of a $4 billion-a-year market.

https://growthhackers.com/growth-studies/red-hat-how-they-de...

I think that makes it important to consider revenue.

Say each company spends ¼ of revenues paying developers. Microsoft would be paying ~10x the developers to write software and probably be writing more software.

Have you read the Commons Clause license? Do you understand it well enough to back up those absurd claims you're making?

People see "oh it's not OSI-approved" and just de-facto assume it's the end of the world.

Redis is an amazing piece of open source, BSD software and you're taking a huge dump on it and its author for not complying to your wishes. Friend, have you done for open source even 1/10th of what Antirez and the Redis project have?

Honestly, this whole thread. I remember instances of people finding out about major figures in open source burning out, turning to drugs or even killing themselves and being all like "oh, this was so preventable".

Prevent now. Stop behaving like this towards people.

Your comment is not productive. It attempts to substitute emotion, misplaced empathy, and ultimately social shaming in place of a discussion of the linguistic and economic issues that this Redis affair is surfacing.

Your post amounts to a ban on criticism, on made on the grounds that it might make people feel bad. It's an attempt to end discussion, not further it. Much like proprietary software licensing, this approach has been tried many times before and has seen limited success.

Nonsense. I don't have a problem with people criticizing Commons Clause, I have a problem with people acting like Antirez & redis labs are the worst people on earth for choosing it, when they've in fact contributed so much to open source.

You know what's not productive? Lacking empathy. Lacking tact. Lacking decency. You wanna have a discussion on Commons Clause, there's a perfectly respectable thread two posts over on Drew DeVault's blog post.

> I don't have a problem with people criticizing Commons Clause

Okay, but...

> You wanna have a discussion on Commons Clause, there's a perfectly respectable thread two posts over

... you do, evidently, have a problem with discussing the Commons Cause: you want to sequester this discussion into its own thread despite the Commons Clause very much on-topic here. You are attempting to smear critics of Redis's use of the Commons Clause by claiming that criticism amounts to treating CC's proponents like "the worst people on earth". This tactic does not lead to the kind of discussion that enlightens or convinces. It lacks tact and has no place here.

My post meant to say that there's reasonable discussion out there I don't have a problem with. Your post however, I have a problem with, as with the tone of many people in this thread.

It's inappropriate and it is the tone I've seen of people who have driven various open source maintainers to burnout and much worse. So yeah, I have a fricking problem with that.

Weak dodge.

Would you please stop posting to HN in the flamewar style? It lowers the discussion and evokes worse from others. We're trying to do better than that here, and I feel like we've asked you this many times already.

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

If a project is licensed "BSD + antithetical_term" or "Apache + antithetical_term", then the names of BSD and Apache should not be invoked.

They are free to make a RedisLab license though.

Redis core is just "BSD", nothing attached.

Best to check the source, license unchanged: https://github.com/antirez/redis/blob/unstable/COPYING

Thank you Salvatore for Redis, it has benefited so many projects.

This should be the top rated comment.

I wish people would put the pitchforks away, and acknowledge the challenges of funding a successful Open Source project.

> An example of such module is RediSearch: it was AGPL and is now going to be Apache + Common Clause.

Sounds to me like the right thing to do here for Free Software proponents is to download the latest AGPL RediSearch, fork it and continue development.

HN needs a feature to say, "Hey! We haven't talked in forever, wanna catch up?" when we notice comments from people we worked with many years ago but haven't talked to in forever.

Who exactly would continue the development in this case? Weren't Redis Labs the biggest contributor here?

Closely related: "The Commons Clause will destroy Open Source" https://news.ycombinator.com/item?id=17818407

As the author of that article, I want to clarify that I was aware that Redis core was going to continue to be available as BSD and incorporated that information into my article. antirez, if you have any comments or corrections I'd be happy to include them in the article.

And https://news.ycombinator.com/item?id=17814386 .

Even if Redis were to change license, the ones who would be to blame are the big cloud providers that re-package OSS products and rent them without giving anything back. They are milking the work out of these projects, taking only the opportunity to make money out of it.

I remember talking to Elastic and they had a similar issue where AWS would take their product, package it and not give anything back (money or patches).

Obviously it's permitted by the license, it doesn't mean that it's right.

Why would this tweak the developers. Isn’t this precisely what the license they chose was made for to include and allow?

In this case Amazon functions like a hosting company. So would you be surprised if a hardware vendor automated the install and patching of Elastic? They’re basically just installing OSS for end users.

I think that this clears up questions about redis itself, but doesn't address the concern than future development will be focused on new modules rather than the core - akin to Google Play Services vs. Android.

> doesn't address the concern than future development will be focused on new modules rather than the core

which is a very valid thing to do, since dev costs money.

I'm not arguing that, and am personally not outraged by it, but in that context I do understand what seems to be a sense of betrayal on the part of OSS stalwarts, even as redis remains BSD licensed.

They have a right to do it but then they're making proprietary software and people who like open source software are free to not like/support them as a result.

Personally I'll keep working on the Redis core, plus the Disque module, that will be developed under the AGPL license (not Common Clause). So you can expect me to be focused on the core as usually.

It makes me wonder if we would have ever received an open-source redis-cluster if it was developed today, and it makes me afraid that it won't stay open like today.

InfluxDB moved their cluster implementation to their enterprise product behind an undisclosed amount of dollars if you want to self-host.

IMO people in the original thread had a pretty good understanding that Redis core was going to have the same license, and some of the modules RL developed would be proprietary (sorry, "source-available").

I think many people are just plain unhappy with that situation, no misunderstanding. I read comparisons drawn between android, taking more and more out of the open source core into proprietary modules, among others.

It was pretty clear to me on reading the RedisLabs page that Redis itself would be BSD licensed.

And, FWIW, I totally sympathize with the motivations behind their decision. I suspect we'll see variations of this in a variety of projects (if not module licensing, then enterprise-only features, reduced work in the open-source version, etc.)

> It was pretty clear to me on reading the RedisLabs page that Redis itself would be BSD licensed.

The page has been updated since the original announcement.

The underlying clarification makes sense, sort of. Is it correct to say that, "These specific modules were developed solely by Redis Labs and are free of any open source contributions."

I understand that the previously licensed versions of the modules will retain there old license and people can choose to contribute or not, on a go forward basis (based on the common clause). However, if FOSS contributions were made (in mass), it still seems a little unctuous.

Isn't this what Google pulled with Android? First it was open source. Then there were closed source Play Store Services. Then Google products required the Play Store services. Then third-party Android distributions stopped working. Now you do what Google tells you to do and pay them what they want to be paid to use Android.

This still doesn't sound good. Even I don't like the fact that AWS is extremely bad at giving back to the community but it is not like doing things like this will make people use RedisLabs. Infact, I will be wary of using these modules for the fear of getting locked with a vendor.

I have used both Elasticache and RedisLabs and can say both have their advantages and annoyances. Elasticache is way easier to set up and configure. RedisLabs puts a lot of artificial restrictions which you have to work around. Also, their pricing model is kind of screwed up. The only major problems I have seen with Elasticache are: Locked APIs, no way to scale instance once created with live traffic, A-Z failover sucks and no persistence.

>We at Redis Labs are sorry for the confusion generated by the Creative Common page, and my colleagues are working to fix the page with better wording.

So I'm not the only one mixing up "Creative Commons" with "Commons Clause".

Small nitpick: the "most permissive license ever" is the FPL/0BSD: https://opensource.org/licenses/FPL-1.0.0

Seems a severe case of "we tried really hard to obfuscate our words with marketing bullshit speak and then it backfired and we got a shitstorm instead, because noone understoond what we were really trying to say".

RedisLabs needs to clearly mark which of the following versions of these modules are freely redistributable as part of a larger project or service.

  neural-redis BSD
  RediSearch AGPL
  rediSQL AGPL-3.0
  ReJSON AGPL
  Redis AGPL
  redis-cell MIT
  Redis-ML AGPL
  redis-timerseries AGPL
  cthulhu BSD
  rebloom AGPL
  redis-cuckoofilter MIT
  redis-roaring MIT
  redis-tdigest MIT
  Session MIT
  countminsketch AGPL
  topk AGPL
  ReDe MIT
  commentDis MIT

Just as a curiosity, Redis Labs is offering a hosted Memcached service, so they are a cloud provider profiting from open-source software they did not significantly contribute to. Just saying. (More seriously, I think the only mistake they made was communicating this license change badly, and with too much whining about how unfair it is that people do what the license explicitly allows them to do.)

It's a proxy that targets Redis actually.

BSD: Freedom for the developer

GPL: Freedom for the user

You've made your choice.

This Redis-compatible alternative is also BSD licensed:

https://github.com/ideawu/ssdb

And it doesn't require the dataset fit in RAM.

antirez: I understand your frustration and don’t mean to take away from the message, but please consider removing “fake news” from the wording. It unnecessarily politicizes the post and really leaves a bad taste.

“Fake news” is the term of art that politicians are using to criticize true stories that they don’t like.

In this case, you’re trying to correct an actual falsehood. The spreading of falsehoods and their being difficult to correct is as old as time and nothing new to this era.

Thank you for listening, and for Redis, as always.

Thanks, I removed fake news because I've the feeling that in US it is used by right-wing people, here in Italy it's the current government that is the master of fake news and is used by our left-wings to criticize what they do. In the doubt I changed the wording. I did not expect the term to be political.

Thank you.

> Thanks, I removed fake news because I've the feeling that in US it is used by right-wing people

It's a term used by both the left and the right. By politicians and the media.

> In the doubt I changed the wording. I did not expect the term to be political.

You shouldn't have. Who cares if it is political. You are the author and you should express yourself the way you want.

He cares, because he wasn't trying to be political.

You could try being literate.

Personal attacks will get you banned here. Please don't post like this to HN.

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

Of course, because sdfjhzhawrnzhj zsfdjhisf ZSDHJyief.

(Closed captions: "you should express yourself any way you want - if you don't care about anybody understanding your message." That is actually the opposite of communication: mumbling to yourself in a one-person language about nobody taking the effort to understand you.)

I've the feeling that in US it is used by right-wing people

No, both sides love using the term about anything the other side says.

And in removing the reference, he removed any association to "sides" in US politics.. don't really need that especially when dealing with a PR issue such as this.

Ok, good reason to avoid this term. Indeed here it's happening as well... instead of understanding that the point is always to verify the information and their sources, "fake news" is becoming a quick way to dismiss what other people are saying, without actually bringing any more source.

Its actually getting pretty hard to write anything these days without someone getting offended (witness the message you are replying to).

In a lot of ways, I really don't blame the current political climate, because the US has seen way worse (read up on the US 1800 Presidential Election). I actually blame poor applications of algorithms to what folks view. The bias caused not only by the beliefs of the person training the box and the professional poster's ability to learn how to manipulate the results (the next generation of SEO) has increasingly made twitter and facebook painful to use. Add a large bit of tribalism that is baked right into humanity and you have a lot of fun. Further strain through the idea that a lot of companies won't even just let the users pick accounts they always want to see regardless of the beliefs of the provider, and you get a added bit of helpless feeling in the populace.

Which makes writing a pain. I've seen some folks take offense at grant applications that are basically some of the most dry reading you will find. It once was a don't use this era's forbidden words (e.g. the word "empower" had a very strange evolution in grants). Now its memes.

Yup — and in fact I recall that it was used very shortly after the 2016 presidential election as the Left, stunned at its loss, was searching for reasons why the election didn't go their way, and latched on to the idea that it was 'fake news,' basically people confusing Onion stories for real life (well, not just Onion-level satire but also carefully-crafted non-satirical false-fact sites). I think the term was then picked up by the Administration shortly after the inauguration. I think at the moment it tends to be used mostly by the Administration, but the term itself seems to have some currency in industry as well, although it may be dying a bit at this point.

Regardless, the term 'fake news' is IMHO itself kinda fake news.

Even though this comment got downvoted for being overly political, antirez is right, that "fake news" holds completely different associations across the world, depending on who uses this term in a particular country.

The history of the term is a little funny. It had two distinct meanings during the course of the US 2016 election, shortly before it escaped to the rest of the world.

The first was the brief phenomenon of websites actually spoofing real news sites with confusing URLs and similar styles - think phishing for news. One example of this was "abcnews.com.co": see e.g. https://timesofsandiego.com/wp-content/uploads/2016/12/Fake-... They would generally publish intentionally false stories with the goal of getting social media clicks and/or influencing public opinion, and usually in the direction of influencing public opinion in favor of US right-wing politics.

The second is the accusation of US right-wing politicians that mainstream journalism (the real ABC, etc.) is publishing intentionally false stories on their actual sites. This use of the term "fake news" pretty efficiently displaced the previous meaning, and left us with no real term to talk about that phenomenon. It generally implies that stories are being made up out of whole cloth with the intent of lying to the public.

At some point, thanks to repeated use of that phrase by the country that dominates the worldwide media, it escaped to the rest of the world - apparently to left-wing folks in Italy as well as to dictators across the globe. Assad has complained about living in a "fake news era". An official in Myanmar has called the very existence of the Rohingya people "fake news."

There has been a phenomenon, for probably as long as recorded human history has been around, where storytellers and journalists get things wrong because of human fallibility and not malicious intent. I think it's easy to understand why people would misread the announcement, and no accusation of malice is required.

The lessons learned here is don't use any word that is being used by US politicians. As Americans are extremely sensitive to politics.

Although I do understand your frustration with news media and the echo chambers echoing precisely the wrong thing without making any attempt in correction.

> I removed fake news because I've the feeling that in US it is used by right-wing people

It was adopted by right-wing (specifically, pro-Trump) people in the US specifically to drown out its earlier use to describe pro-Trump propaganda that followed what RAND Corp had described as the “firehose of falsehoods” propaganda approach used by Russia in other contexts (and which, it is increasingly evident, did so because it was in fact, often engineered by the same people who engineered the Russian propaganda that that label described.)

Antirez, don't worry about it! It's a very effective and accurate phrase that inflames a small minority of overly vocal folks who are irritated that the double standard in left-leaning western media is now becoming better understood. Anyway, enough of that, thanks again for your incredible contribution to humanity.

(What I want to know is how does that #$%^ing page hijack the font even in Reader Mode!? WTF! I want serif body fonts goddamnit.)

The body text is contained in a <pre> tag with newlines for paragraphs instead of the correct <p> tags. You can force Firefox to respect your font choice by adding a font:inherit to the <pre>'s css with the developer tools. This will break pages with correctly used <pre> tags.

Thank you! You're too kind.

> I think that Redis Labs Common Clause page did not provide a clear and complete information, but software companies often do communication errors

In their defense, many programmers can be so spiteful and cynical that basically nothing could've been done to change this "communication error."

It's helpful that Salvatore clarified, but I suspect that there are many who won't care or won't be convinced. The headline is all they needed to trip their "GTFO" line.

Personally, I think the move was fine. There are much worse companies out there.

Reply on news.ycombinator.com