Hacker News new | past | comments | ask | show | jobs | submit login

IMHO this is gonna kill Redis Labs just like Hashicorp is getting owned and seeking a buyout, and not stop anyone from ripping off Redis Labs, because the folks who truly suffer from this are the small startups who just want to use Redis cache without legal bullshit, whereas for AWS to fork Redis is doable and they could even turn it around and make their fork permissively licensed which suddenly makes Redis Labs into the worse choice in terms of license.

It’s a hard choice to make, but imho either keep your code proprietary or stick with “Apache OR MIT” … all this stuff about switching licenses partway down the line is really lame and just seems destined to backfire.

Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck, then it’s not going to hurt the big corpo teams, but rather the users. Big corpo teams are users too, they don’t want to deal with this legal mess either. Like it or not, Redis has always been a permissive open source project which is why it has been a success. Changing that is changing the equation in that regard going forward and portends bad outcomes for everyone involved.




I think this pretty much kills the idea of Corporation being a good stuart of Open Source Software user needs over long term...

We need to better recognize the difference between "Foundation" owned software like PostgreSQL vs Corporation Owner like Open Source. When you focus in "Maximizing shareholder value" the goal of keeping your user freedoms will inevitably be put aside.

It would be much better choice for Redis community if Antirez would seporate his employment from Project ownership and leave it in hands of some non profit. Something like Apache Redis would be much better for community and it also would allow Redis Labs to build proprietary extensions and cloud business around it.


> the goal of keeping your user freedoms will inevitably be put aside

That depends on who you consider the user. If it's the person buying managed redis, then this license change doesn't affect any user freedoms.

I don't know, it feels like this way of doing things doesn't work well, but pure open source also doesn't work well when you want to pay salaries to a bunch of devs.


Disclosure: I work for a company with a free downloadable software package, paid plans, and write a lot of open source around it.

I wrote about this conundrum a few years ago: https://www.mooreds.com/wordpress/archives/3438

OSS is a great way to build a community, increase adoption, and get attention. It isn't perfect at that, but it beats alternatives, for devtools at least.

But then you need to make money (especially if you've taken VC).

That's when the problems start. It's hard to make money on OSS unless you are using it as a complement to something you can sell. Especially in the age of hyperscalers.

And, as other posts indicate, switching from OSS midstream burns any goodwill you had when you started, and opens you up to forks.

It's not unique to OSS, though. Even devtools that cost money or are free but not OSS run into issues making money. Devs are a hard audience to sell to, in my experience. I know I am stingy.


> Devs are a hard audience to sell to

no, devs aren't hard to sell to. It's business owners that are hard to sell to.

If you are running a business, every cost needs to be controlled for you to be profitable. Adopting open source is a form of cost control.

The problem of OSS is that the value proposition is that it is free-as-in-beer (as well as all of the benefits of OSS). So if/when the software becomes not free-as-in-beer, the company will have to reconsider, or change, or eat the cost if the cost is lower than the value generation of the software.


The value of open source is that I don't have to waste my time negotiating contracts to license the software, I can make improvemwnts and customizations to it, I don't have to accept changes from upstream that are detrimental to my business, and no one can take it away from me.

Open Source may also be less expensive, but I am paying with some combination of time and efort and support contracts or other service and sponsorships.


It very much does. If I'm buying Managed Solution I want to have a choice of multiple providers which are free to innovate and compete. If they have to have agreement with vendor we have situation no different than hosted Oracle


Over the years I've come to agree with this POV, and distilled it down to this:

If your goal is profit, don't open source your core product.

We've seen this time and time again where a company releases their core software under a permissive license, and then bigger competitors come along and resell a solution redistributing their software.

If the company's central goal is profit, this is an existential threat. However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!

This doesn't apply to software that's secondary to your core product, e.g. a useful tool you've developed but don't make money directly selling to others.


> However if your company goal is to ensure the software exists (as a non-profit steward), this is a resounding success!

That depends on whether those big competitors are contributing code back.

If they are, then great, the code continues to exist as high quality open source, even if you're playing a smaller role.

If they aren't, then the good version isn't open source. Your goal is failing even when you ignore profit. And at that point maybe an "open source except for those guys" license gets you closer to your goal in practice.


Contributing code back alone doesn't help, if there isn't any sustainable source of income, those devs aren't going to pay supermarket and the landlord with the pull requests from big corp.


If your goal is just to make the software exist, then being put out of business isn't a problem. Which is how I read the hypothetical.


It is piramid, before the software gets to exist, living must be possible.


Yes? I don't see the issue here, except that old observation that entities built to solve a problem almost never want to shut down once the problem is solved.


> If your goal is profit, don't open source your core product.

Or more fundamentally, don't open source your value prop. Open source your complement. So many OSS shops build a valuable core only to realise their actual business ends up being selling managed servers.


Your "product" is what you sell. The owners of redis labs don't sell redis, they sell hosting, as far as I can see, in which case they made themselves a competitor to AWS, Azure, etc. And they don't have a competitive advantage in that. Also, why should AWS not compete back? Is a hosting company supposed to sit back and watch another hosting company just win business?


> And they don't have a competitive advantage in that.

Sure they do. As the original authors of the product, they should have the best understanding of its features, and are in the best position to augment it in ways other pure hosting competitors can't or won't. They have first-mover advantage to build novel features, and integrate them into commercial propositions that benefit their customers first. They should also know best how to deploy and scale the product, even if their competitors excel at this.

If Redis Labs wasn't able to compete with AWS and other pure hosting providers, then they failed at taking advantage of their position. This is not an indication that the open core model can't be successful for both OSS users and the business. E.g. see Grafana.

Of course, this also depends on the nature of the product. A general purpose database or another core infrastructure product is much more attractive for hosting competitors than a purpose-built product.


> If your goal is profit, don't open source your core product.

It's not hard to create a profitable business on open source and make good money. The question is how much.

If your goal as a founder is to be a billionaire, open source products are not going to do it. You need monopoly-level rents to do that, like Oracle or Snowflake. There's plenty of opportunity to create millionaires. But you'll have to forego VC financing to do it because that math does not work for venture capital funds.


Open Source has a) you guys implement it b) we sell it, thanks problem.

This license change addresses this very problem so cloud mega corps can't leech.

For me it sounds like better AGPL.

I don't give a shit about philosophical nuances and OSI-approved list – at the end of the day this is much less restrictive license than AGPL - I have source code, I can run it locally, I can run it on my projects, I can run it on my commercial projects, I can run it where I work, I can use it on bare metal, VM, Docker, k8s and from Azure the same way.

The fact that Microsoft will have to share cut of the premium they're already charging is irrelevant to me – if anything I applaud for finding sustainable business model around it.


As opposed to leeching from open sourcing your software just to undercut the competitors and then bait and switch into closed source? There's absolutely no problem with wanting to sell your software and being proprietary. But the issue is really that they are a multi million or even billion (hashicorp) who built that value on top of being open source.

They are completely within their right to switch licences but it doesn't mean that we have to fall for the narrative that they are protecting themselves from the big guys. Let's be honest, no one would've used redis or terraform if it was closed source. Or if it wasn't available on the big guys platforms.

Redis started as a community project and had tons of community contributions. I'm sure that their effort to gain fairness for the smaller guys doesn't apply to anyone smaller than them. It's ironic that they did exactly what they imply the big cloud players did, scoop up open-source work to build corporate value


Wait, no. You can't run it for anything commercial unless you pay up. That's their whole spiel.


Of course you can.

You can't if your offer directly competes with redislabs - ie. you are cloud provider and you're selling redis as a service. You have to share your profit margin with them through licensing in this case.


> directly competes with redislabs

not having read the license (and not a lawyer), i dont know how far or direct it must be for it to be considered directly compete. Surely it's a very blurred area, which would then be rife with risk for anyone to adopt redis from now on.


It's explained in FAQ section.

Reselling redis-as-a-service or not is clear cut to me.

I'm not so much interested in philosophical explorations of theoretical "what if I resell redis but without this and that command?" cases either.


All legal risks are theoretical until you get sued.


There is no legal risk if you adhere to plain license terms.


I look at the SSPL and don't see plain license terms. I see vague restrictions almost designed to provide opportunity for exciting future litigation.


It's dual licensed.

It's your choice between SSLPv1 or RSALv2.

If your product is open source, then you choose SSLPv1 and you're safe.

If your product is closed/commercial, then you choose RSALv2.

You probably want to look at RSALv2 [0] instead of SSLPv1. It's very short, plain and simple.

With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals. If it does that then you need to enter agreement with Redis Labs to share your profit margin with them.

Ie. if documentation for your offering redirects users to redis docs for usage of your product – you can't use RSALv2 because you're directly competing with Redis Labs with your offering.

This means cloud providers are directly impacted, not usual businesses that USE, not OFFER redis.

And frankly, that's the way it should be. This is the way to do sustainable, source available, open source compatible (through SSLPv1) business model.

[0] https://redis.com/legal/rsalv2-agreement


> If your product is open source, then you choose SSLPv1 and you're safe.

If I choose a dependency that's SSLPv1 licensed, my product is no longer open source.

> If your product is closed/commercial, then you choose RSALv2.

From the limitations section of the RSALv2:

> You may not make the functionality of the Software or a Modified version available to third parties as a service or distribute the Software or a Modified version in a manner that makes the functionality of the Software available to third parties.

What does this even mean? The functionality of Redis is to store data and then make it available on request (typically over a network), therefore this clause means I'm not allowed to use it in any system which exposes the capability of storing data for end users and making it available on request. For example, a product that allows a user to set some preferences.

If it doesn't mean that, why isn't the licence more specific?

> With RSALv2 you're safe as long as your product is not a wrapper/database aimed at developers that just exposes redis internals.

It's delightful that you infer this. However, this is not what the licence says.


I stand corrected for this sentence saying that SSLPv1 is open source license, it's not OSI approved [0], even if people using it claim it's open source (it was created by MondoDB IIRC and adopted by others).

From user's perspective it's open source. From provider's perspective it's not. OSI doesn't distinguish between those two, there is only user, which can be ordinary end user or provider. Because for provider it's not open source, it can't be approved OSI license.

For RSALv2 "Software" and "Modified" is not "software" and "modified". It's capitalized because it refers to terms that are provided in "Definitions" section. From there you have:

    Modify, Modified, or Modification: copy from or adapt all or part of the work in a fashion requiring copyright permission other than making an exact copy. The resulting work is called a Modified version of the earlier work.

    Redis: the Redis software as described in redis.io.

    Software: certain Software components designed to work with Redis and provided to You under this Agreement.
Plain and simple.

It's also plain and simple to see why those things are created in the first place. It's because open source has problem with cloud where big players not involved with the project cash out on it by simply selling it as is (as managed service) and by doing it they also automatically strip original authors from any chances of competing.

This effort is targeted solely on cloud providers so original authors of the project get a chance at having viable, sustainable business model.

It's not targeted at users. It's targeted at providers.

SSLPv1 was added into dual licensing to allow open solutions to allow to exist – ie. projects that extend redis but don't monetize on it.

ps. OSI doesn't have (or will ever have?) licenses that are compatible with this new era of cloud providers because it equates end user with cloud provider. This is wrong and people will have to invent new adjectives/nouns to describe what they mean by open source contribution + not allowed to leech on us (compete with us through cloud offering without giving us a cut).

[0] https://opensource.org/blog/the-sspl-is-not-an-open-source-l...


> For RSALv2 "Software" and "Modified" is not "software" and "modified". It's capitalized because it refers to terms that are provided in "Definitions" section. From there you have:

Notice how they deliberately don't define "service" or at any point specify "the functionality of the Software".

> It's because open source has problem with cloud where big players not involved with the project cash out on it by simply selling it as is (as managed service) and by doing it they also automatically strip original authors from any chances of competing.

This is, quite obviously, highly subjective. I (and many others) don't think there's a problem, VC-backed companies think there's a problem. Go ask (for example) the Linux, Postgres, Memcached or any of the CNCF folk about whether there's a problem.

> It's not targeted at users. It's targeted at providers.

Providers are also users.

> OSI doesn't have (or will ever have?) licenses that are compatible with this new era of cloud providers because it equates end user with cloud provider. This is wrong and people will have to invent new adjectives/nouns to describe what they mean by open source contribution + not allowed to leech on us (compete with us through cloud offering without giving us a cut).

It's also pretty insulting to the thousands (millions?) of open source projects that choose to adopt an OSI-approved open source licence to suggest that they somehow don't understand what they're doing or are "doing it wrong".

If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?


> If you're worried about not getting a cut when cloud providers use your software to make money.... don't release it under an open source licence. This isn't hard?

End use != provide.

Open code, open contributions, open non-commercial applications matter.

It's a simple 2 dimensional space on:

Usage(Use, Provide)

Setting(Commercial, Non Profit)

With single false cell on Provide & Commercial.

Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.

If you don't want to use it on your copyrighted work, don't.

It doesn't mean others are not allowed, does it?


You seem extraordinarily sure that the definition of "provider" or "provides a service" (or even "end user") is universally and objectively understood by all, and yet you can't point me to the place where Redis (or anyone else) spells this out. Curious.

> Copyright holders should be allowed to choose this option. I don't see why the whole fuss about why not.

I agree. As long as they define their terms. Redis haven't. That's the point.


It's clearly stated in Definitions section (for Modify, Modified, or Modification).

It draws clear distinction between merely USING the software in its original form and ADAPTATION or DERIVATION that requires copyright permission.

It plainly, simply and directly implies that using it is fine and distributing modifications is not. It also says that unmodified version is fine to distribute commercially ("... other than making an exact copy").


There is a real, non-negligible cost to dealing with even baseless lawsuits. With that said, essentially any decent insurance company will usually be able to price that risk into a shockingly-low cost policy for you (think <0.1% of at-risk revenue).


There is no problem with baseless lawsuits in this case.

It's plain and simple distinction between USE and PROVIDE.

Users don't care.

Providers are upset because they can't leech on this work anymore and have to share their cut with upstream.

From user's perspective it's open source.

From provider's perspective it's not.

ps. as a user I also do care about the fact that upstream has found sustainable business model because it means people on the payroll working on it while I can freely use it, inspect and contribute to the code. Frankly I don't want more from open source. I even like it more than SQLite's Public Domain which does not allow upstream contributions.


> Open Source is about user ownership of software.

No, OSS developers retain authorship (with the exception of public domain). Only the authors can change the license and terms. Users get a license to do various things with the software/code, but they do not get ownership.


Authors can only change the license if they are the sole authors or if they impose a CLA requiring others to grant re-licensing to the original authors.

A copyleft project with no CLA, levels the playing field so that everyone has the same rights. Eg.: Linux kernel


> Open Source is about user ownership of software. If we try to get around that with legal trickery to make a buck,

See: Enshittification. Totally agreeing with you, but this feels like just another data point to Cory's thesis.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: