[HN Gopher] Redis adopts dual source-available licensing
___________________________________________________________________
Redis adopts dual source-available licensing
Author : pauldix
Score : 275 points
Date : 2024-03-20 22:06 UTC (1 days ago)
(HTM) web link (redis.com)
(TXT) w3m dump (redis.com)
| reconditerose wrote:
| Redis Inc. is moving the https://github.com/redis/redis/ project
| away from the three part BSD license to a dual license using two
| non-OSI approved license. This comes after previous comment from
| them saying that "... the Redis core license, which is and will
| always be licensed under the 3-Clause- BSD".
| (https://redis.com/blog/redis-labs-modules-license-changes/)
| rsstack wrote:
| Thanks to MBA CEOs taking over companies that adopted (not even
| developed) Open Source projects...
| reconditerose wrote:
| Yeah, https://redis.com/press/redis-ceo-succession/, seems to
| be the case here. It took them a little over a year to decide
| open-source isn't profitable and move away.
| pauldix wrote:
| Revenue through hosting continues to be the big driver for all of
| these projects, which is what is motivating the license changes.
|
| The trend indicates that only open source libraries work for
| companies that own projects. If it's a program (e.g. server
| software like a database) then it's either source available or
| under a foundation. It's tough and I don't know what the answer
| is here.
|
| I'd love to see a model that causes the pendulum to swing back
| the other way with open source permissive licenses for complex
| programs, but I don't see a viable way yet. Maybe trademark
| enforcement and open source code only with licensed builds?
|
| Either way, I'm sure we'll continue to see the rise and fall (or
| license change) of popular open source software for years to
| come. There's too much benefit for developers and companies to
| start out open source. And there's too much pressure later on to
| change it.
|
| At the very least, I'll give Redis credit for giving far more
| value to the world than they've captured. By an absolutely
| massive margin.
|
| It'll be interesting to see how long a fork takes to land and if
| it'll be successful. And it'll be interesting to look at Redis
| (the company)'s revenue growth curve in 5 years.
| _msw_ wrote:
| Personally, I don't find foundations to be a magic solution for
| this problem. There are many examples where a single company
| has decided to basically "fork" their way out of foundation
| housing and the community is left with the same outcome.
| justinclift wrote:
| > open source permissive licenses for complex programs
|
| Like the AGPL3?
|
| https://spdx.org/licenses/AGPL-3.0-or-later.html
| pauldix wrote:
| Copyleft isn't permissive. It's a viral license that sets
| restrictions on derivative works, forks and contribution.
| dartos wrote:
| Permissive meaning "freedom" (the eff definition) in this
| case.
| Brian_K_White wrote:
| And thank deity for it!
|
| Holy cow am I so glad for every line of that viral leftist
| restrictive code!
| Andrex wrote:
| The more GPL code there is in the world, the better off
| everyone (consumers and business owners both) are.
| Brian_K_White wrote:
| What virus ever gave you the option of "oh in that case, no
| thanks, I'll do it some other way" ?
| klabb3 wrote:
| > Revenue through hosting continues to be the big driver for
| all of these projects, which is what is motivating the license
| changes.
|
| Yeah, isn't this just massive cloud providers eating the lunch
| of Redis etc? I don't know enough about the licensing but I
| highly empathize with these small-mid sized companies building
| foundational tech that is commoditized and upcharged by an
| oligopolistic cloud behemoths. Surprised it's taken this long.
|
| Question: what other alternatives than license changes are
| there, assuming we want a healthy ecosystem of both businesses
| and open source?
| pcthrowaway wrote:
| TimescaleDB has an open core style license that seems to
| prevent the cloud services from repackaging their DB.
|
| It's not technically fully open source, but it's pretty close
| to it.
|
| Actually, I just took another look and they now market their
| "open core" as the apache edition (or perhaps have diverged
| from the "community edition" now)
| michaelmrose wrote:
| > open source code only with licensed builds
|
| That isn't open source.
| joshuaissac wrote:
| > That isn't open source.
|
| It is open source if the source code is available under an
| open source licence.
|
| For example, OpenJDK is licensed under the GPL and Oracle
| provides licensed builds, but that does not make OpenJDK not
| open source.
| pjmlp wrote:
| It would also help that many developers would acknowledge that
| we are no different from other professionals, expecting to be
| paid for our own work, while not wanting to give a dime for the
| work tools doesn't scale.
|
| Those producing work tools also have bills to pay.
|
| In a way, developers themselves are to blame for the failure of
| the FOSS dream.
|
| Slowly we are back to the public domain/shareware days.
| LightFog wrote:
| Developers are entirely to blame - the fraction of developers
| meaningfully contributing to FOSS or advocating for
| supporting it is tiny. Just 'import foo' and holy smokes -
| free shit, yes please!
| jarpineh wrote:
| I can't see how you can shoulder the blame of (possible)
| failure of FOSS dream on developers. Devs (usually) don't
| control budgets and can't really ask for money to pay for
| freely licensed code. If blame is to be given then I'd point
| to money handlers for not acknowledging this situation.
|
| Then there's the question of what I should be paying anyway.
| Who among all those non-free developers are paying in turn to
| all the professionals whose code they build on? Are
| proprietary developers somehow exempt from paying themselves?
| If and when I choose to pay I like to think all that
| contributed are getting the benefit.
|
| There's a long line of professionals behind every code that
| should have been paid. Certain percentage might have tried to
| get paid. And even some who in fact did get paid.
| pjmlp wrote:
| Easy, there is no need to try to use every tool under the
| Sun.
|
| Do as we did before the GNU days, analyse what really
| matters for a specific project development, pay for those
| tools, and keep using them until they aren't suitable any
| longer.
| jarpineh wrote:
| Ha. I'm not sure your remark really responds to my
| concerns. I do use very small set from all the things.
| And do pay (small amount, I admit) money to some of them.
|
| If I choose to pay for a tool and the tool maker doesn't
| pay for their tools, then how much better off we are? I
| can't really see this next iteration of non-GNU ecosystem
| faring that much better if only few benefit.
|
| And for that matter, I _did_ pay money for non-free
| tools. And bought Linux on those CDs distributors used to
| sell. Then the free-er ones somehow got better, so that
| revenue stream had nowhere to go. As I said, there 's no
| easy way to pay for free stuff.
| mindcrime wrote:
| Just in case anybody needs it, here's a fork from the last commit
| before the license change.
|
| https://github.com/mindcrime-forks/redis
| mdaniel wrote:
| what a perfect org name for capturing these rug pulls, second
| to "github.com/lol-our-incredible-open-source-journey" or
| "gitlab.com/but-aws-gonna-steal-our-shit"
| mindcrime wrote:
| Honestly, I created it just to keep things organized. I fork
| a lot of projects for different reasons, but mostly just to
| keep a copy around for when "weird shit happens". Eventually
| I had some many forked projects in my "mindcrime" org that
| they got in the way, so creating a "mindcrime-forks" and
| moving all the forks there seemed like an obvious choice.
|
| I also did a "mindcrime-templates" for template pom.xml
| files, and silly little "starter projects" of various sorts
| that I can clone down and and have something set up the way I
| like it, with minimal scaffolding, and then start morphing it
| into whatever I need.
| wmf wrote:
| The use of the word "permissive" here to describe super-strong
| copyleft licenses is uh, interesting.
| https://en.wikipedia.org/wiki/Permissive_software_license
| justinclift wrote:
| That doesn't seem accurate?
|
| Did you misread the first paragraph of that wikipedia entry,
| where it defines the term as pretty much opposite that, or am I
| misunderstanding what you're meaning?
| wmf wrote:
| Redis is using the wrong definition of permissive.
| hintymad wrote:
| What does dual license mean here? Does that mean that Redis is
| subject to one of the two licenses, or to both of them?
| wmf wrote:
| You can choose either license.
| _msw_ wrote:
| That's not strictly accurate. SSPLv1 is only a choice for the
| source code. One can elect to use RSALv2 for both binaries
| and source code.
| RicoElectrico wrote:
| So far, the most viable route of FOSS monetization seems to be
| "open core". Android, SQLite, GitLab, VSCode, Docker to name a
| few.
| wmf wrote:
| Open core companies, including Redis, are the ones switching to
| fake open source licenses.
| RicoElectrico wrote:
| Indeed Redis was open core before the switch, sorry that I
| didn't check. And being open core was not enough for them,
| SMH.
|
| Maybe such is the destiny of foundational open source server
| software... If it's "cloudable" no profitable business will
| come out of it.
| reconditerose wrote:
| Redis was open before the trademark was acquired from
| antirez by Garantia Data, who then re-branded themselves as
| RedisLabs, and then as Redis. This was definitely not a
| predestined outcome, there are plenty of other foundational
| open source server software that transitioned to a software
| foundation. While I worked on the redis core team
| (https://redis.com/blog/new-governance-for-redis/), I
| advocated to move it to a foundation.
| wmf wrote:
| Foundations don't pay the bills either; see Linkerd.
| singpolyma3 wrote:
| Yes, but the point is that the project started as, and
| gained success as, a not-paying-the-bills endeavour. The
| fact that RedisLabs desires to get enough to pay a bunch
| of staff is not actually a requirement for redis to exist
| and thrive, they just happen to own the trademark.
| reconditerose wrote:
| Exactly. Redis (the company) had plenty of opportunity to
| monetize either a cloud offering or their enterprise
| offering. They have a lot of cool technology like vector
| search and time series extensions that people will
| readily pay for. They could have found a path of moving
| the core to a foundation and continuing to make money
| with their added value. They're choosing to get the value
| they can out of the open-source stack. It might work out
| well for them, but I can't believe it will be good in the
| long term for Redis users.
| twsted wrote:
| > Maybe such is the destiny of foundational open source
| server software... If it's "cloudable" no profitable
| business will come out of it.
|
| I really hope it's not true, but many clues suggest it
| might be.
|
| I like the concept of open core with a very liberal
| license. Perhaps there should be a special "MIT-X" (an
| example, it would be certainly not compatible) license with
| a clause borrowed from that of Llama2 for large
| organizations, as Additional Commercial Terms [0].
|
| [0] https://ai.meta.com/llama/license/
| miraculixx wrote:
| You means this?
|
| "2. Additional Commercial Terms. If, on the Llama 2
| version release date, the monthly active users of the
| products or services made available by or for Licensee,
| or Licensee's affiliates, is greater than 700 million
| monthly active users in the preceding calendar month, you
| must request a license from Meta, which Meta may grant to
| you in its sole discretion, and you are not authorized to
| exercise any of the rights under this Agreement unless or
| until Meta otherwise expressly grants you such rights."
| miraculixx wrote:
| KeyDB, a multithreaded drop-in replacement for Redis,
| under MIT, owned by Snap.
|
| https://docs.keydb.dev/
| stephenr wrote:
| I realise _they_ use the term "drop in replacement", but
| without Lua support it really isn't.
|
| That doesn't mean it isn't worth exploring but lacking a
| major piece of functionality means it explicitly can't be
| "dropped in" to replace redis.
| justinclift wrote:
| Is SQLite "open core"?
| pjmlp wrote:
| Also known as Shareware/Public Domain back in the old days
| before GNU's adoption.
| xarope wrote:
| This on the heels of microsoft's garnet announcement
| (https://news.ycombinator.com/item?id=39752504)... Would be a
| shame to see this be the death knell of redis.
|
| Or in the spirit of YC, is there yarcdis (yet-another-redis-
| clone-dis) awaiting in the wings?
| dartos wrote:
| Memcached?
| miraculixx wrote:
| Great to see we have alternatives. I think Redis management
| doesn't understand how people choose software these days.
| pjmlp wrote:
| That is why enterprise shops than get all the cool toys,
| because many devs aren't willing to pay for their tools, and
| then they wonder when their toys aren't available any longer
| as the creators got enough CV coverage to get a proper job,
| doing proprietary software for big corps.
| yjftsjthsd-h wrote:
| > That is why enterprise shops than get all the cool toys
|
| ...what enterprise shops are you working in? Everywhere
| I've worked the paid software sucked, often in direct
| proportion to its cost.
| pjmlp wrote:
| Stuff like Clion, Visual Studio, Unity Pro, Photoshop,
| Outsystems, Qt, macOS/Windows vs Linux Desktop, ....
| yjftsjthsd-h wrote:
| Having recently left a job that let me run Ubuntu and
| started a job that forces me to use Windows, that is an
| _excellent_ example of the proprietary /paid option being
| _awful_ in comparison to the FOSS option. The rest I 've
| not used so can't say with any confidence.
| west0n wrote:
| This incident reflects the increasing profit pressure on Redis
| Inc. Furthermore, Redis' competitive edge in performance is
| declining, especially with the emergence of alternatives like
| Dragonfly and Garnet (disscussed here
| https://news.ycombinator.com/item?id=39752504).
| VeejayRampay wrote:
| Garnet was released a few days ago, how exactly is it making
| Redis lose its edge in performance?
|
| maybe we wait for a few months before making wild statements
| like this, software is not about chasing the latest hype
| 8xeh wrote:
| First they break lolwut
| (https://github.com/redis/redis/issues/12074) and now this.
|
| See: https://news.ycombinator.com/item?id=38841284
| reconditerose wrote:
| Don't worry, if there is a fork that is the first thing I will
| contribute to. I build one that prints out various fractals,
| but never contributed it.
| whateveracct wrote:
| the trend of milking revenue from a few sources with license
| changes is cringe.
| theshrike79 wrote:
| The "few sources" here being tiny mom & pop shops like AWS and
| GCP.
|
| I think they can manage.
| kunagi7 wrote:
| Seems like AWS did contribute to Redis and has implemented
| quite a few features [1] and have been partners for quite a
| while [2]. This could not have any effect for AWS but for
| other cloud providers instead.
|
| [1] https://aws.amazon.com/blogs/opensource/how-to-become-a-
| redi...
|
| [2] https://redis.com/press/strategic-collaboration-
| agreement-wi...
| margorczynski wrote:
| People always said that the model for making money off open
| source is support - some company uses e.g. Postgres and they
| require specialists to help them out and put out fires in their
| on-prem setup.
|
| But in the age of the "Cloud" companies will simply use the
| managed offering provided by Amazon/MS/Google/etc. basically
| destroying any financial opportunities for the maintainers and
| other people around the project. Also nobody wants to work their
| ass off on some OSS just to see AWS raking in milions off it
| without contributing back anything.
| _msw_ wrote:
| Disclosure: I work for Amazon, but I don't work directly on
| Redis related cloud services. I _am_ close to the Open Source
| Program Office, and I care a lot about the people who do the
| hard work required to collaborate on open source projects.
|
| Madelyn Olson did the hard work for years to earn the trust of
| other Redis core developers to become a core maintainer, all
| while employed by AWS to do that work. She and other AWS
| developers have contributed a lot to the core Redis engine.
| Some may say that they too worked their asses off for the Redis
| community.
|
| You can read more about some of those contributions here:
| https://aws.amazon.com/blogs/opensource/behind-the-scenes-on...
| klabb3 wrote:
| I think most people are aware of the occasional contributions
| from the behemoths. Sometimes, entire projects. But charity
| is not a sustainable business model. When you provide a
| service offering the marginal returns go to the provider. In
| the B2B world, that's a golden deal for these companies.
| Normally, you'd have a rev share or something like it. So
| it's very understandable there's a shift in the industry.
| It's probably for the better for everyone.
| _msw_ wrote:
| "Occasional contributions" don't earn an invitation to
| become a Redis core maintainer. Please stop diminishing the
| tireless work of FOSS maintainers.
| klabb3 wrote:
| I'm obviously talking about corporate FOSS contributions
| overall, not any individual contributor. There's also a
| difference being on FAANG payroll vs maintaining without
| financial stability, which is the reality for most FOSS
| maintainers.
| arp242 wrote:
| They get paid for it. Don't try to spin this as if it's
| someone people working on it in their spare time out of
| the goodness of their heart. It's just their job.
|
| Amazon simultaneously wants to be "part of the community"
| but also extract the maximum amount of profit via AWS.
| Amazon can just do a deal with Redis to share a
| percentage of the profits from their Redis usage. They
| don't have to, but they could. But no, they insist on
| having it for free, and we should be grateful that
| benevolent Amazon with their $23 billion operating income
| (from AWS) deems Redis worthy for a contributor or two
| (which is of course entirely in their own interest). Give
| me a break.
|
| Amazon Inc. wants to maximize profits. Okay fair. I'm not
| against capitalism. But it holds others to a different
| standard by insisting _they_ only (not Amazon) should be
| beholden to some different type of post-capitalist post-
| scarcity "let's all share together in community" type of
| model and cries crocodile tears when they model of
| extracting the maximum in profits while giving the
| minimum in return blows up in their face. You reap what
| you sow.
|
| Amazon needs to either hold everyone to the same standard
| as they have for themselves or stop whining.
| reconditerose wrote:
| > They get paid for it. Don't try to spin this as if it's
| someone people working on it in their spare time out of
| the goodness of their heart. It's just their job.
|
| No, you can't have this both ways. I'm the main
| contributor from AWS, and I've worked many times on
| weekends because I care about open source. I like helping
| people, I don't need to be paid to do it. Many of the AWS
| folks that made changes were normal engineers that were
| excited to be part of Redis.
| https://github.com/redis/redis/pull/10419 and
| https://github.com/redis/redis/pull/8621 are both
| examples of features someone from AWS built in their free
| time. We're all upset about this. Not because Redis
| deserves to get paid, it's that they acted like they were
| being good stewards of the open-source community and then
| they changed their mind.
| arp242 wrote:
| I'm sure you do, but that changes nothing about the
| problematic nature of Amazon's relationship with a lot of
| projects it interacts with, which is really what this is
| about: "Amazon thinks that by throwing some contributions
| at a project offsets for depriving a project of its main
| revenue". Well, it doesn't. My landlord and Tesco doesn't
| accept code contributions as payment. This is why this
| keeps happening again and again with all sort of
| projects. You reap what you sow.
| jpc0 wrote:
| > My landlord and Tesco doesn't accept code contributions
| as payment
|
| Your landlord and Tesco aren't an open source project.
|
| If for instance I get paid $X to specifically work on
| Redis by Y. The open source project now has effectively a
| full time engineer they aren't paying for, one that
| likely would not be a full time engineer for redis
| otherwise.
|
| You cannot have "Amazon engineers contribute to redis"
| and "Amazon pays redis $X every month" and Amazon is only
| an example here, it could be Costco or IKEA or whatever.
|
| So your argument is that instead of having OSS
| contributions from some of the best engineers in the
| world, redis (and other now OSS software) should compete
| with FAANG to pay those engineers.
|
| Guaranteed one of the FAANG companies would just develop
| the tools internally instead if paying redis.
| darkwater wrote:
| > You cannot have "Amazon engineers contribute to redis"
| and "Amazon pays redis $X every month" and Amazon is only
| an example here, it could be Costco or IKEA or whatever.
|
| Wouldn't be better for both Redis, community and OSS
| movement if
|
| 1) Redis was fully OSS
|
| 2) AWS has a deal with Redis Labs were they share some X%
| of the revenue of their income for managed Redis
| (ElastiCache)
|
| 3) Redis Labs with that revenue can hire more maintainers
|
| 3a) Redis Labs with that revenue can pursue a competitive
| offering to ElastiCache (booom!)
|
| 4) AWS can still hire their developers and try to make
| them core maintainers to steer Redis development into
| implementing features they want/need
|
| It's really impossible for me to paint AWS as the good
| citizen here and Redis Labs as the villain.
|
| EDIT: I also wonder what history would have been if
| antirez started or moved to an AGPL3 licensing early on.
| jpc0 wrote:
| All this hinges in redis being a for profit with OSS
| software and not competing with AWS, that isn't happening
| though AWS won't happily fund their competitors and
| definitely wont contribute developer time to it.
|
| Redis is partly where it is because of large FAANG
| companies contributing to redis, that cannot be
| discounted.
|
| I don't have the time but go strip out all commits from
| FAANG companies employee and see if redis would be the
| product it is currently.
|
| I'm not saying AWS is right but at the same time that is
| what redis decided to allow when they used the model they
| did. Now that they see they could be making a ton of
| money they want to retroactively change their licensing
| which is arguably also bad.
|
| It's a money grab both ways which is what I have an issue
| with.
|
| I'm pretty sure we will see AWS fork redis just before
| the license change and keep developing from there. They
| could even also then have all new code be proprietary as
| far as the current license allows that.
|
| My argument is the industry in general is probably going
| to be worse of after this move than before.
| arp242 wrote:
| > instead of having OSS contributions from some of the
| best engineers in the world, redis (and other now OSS
| software) should compete with FAANG to pay those
| engineers.
|
| This already happens. Amazon is never the main
| contributor. That blog post talks about 33 commits for
| MariaDB for 2023. Like, that's great and all, but that
| project doesn't run on those 33 commits. It's the same
| with Elastic; when they did their license change I looked
| a bit at the commit history, and something like >95% was
| by Elastic.
|
| And all these projects that did license changes are fine.
| zellyn wrote:
| reconditerose wrote above:
|
| > At that time Redis created an open governing board that
| took over, with a majority of contributions coming from
| the community during this time (~25% of contributions
| came from Redis engineers, ~75% from the community,
| including ~3% that came from me personally).
|
| So, while I believe you're true in the general case, you
| appear to be wrong about Redis in particular.
| ako wrote:
| I question whether AWS is depriving Redis of their
| revenue. You just can't pay every single open source
| author for their work, too much overhead in maintaining
| all the contracts, especially if the software is offered
| as a service. You need the billing in place,
| certifications, support contracts, data sharing
| agreements, etc. As a company you want to optimize the
| number of business partners you have to deal with, and
| this is the value AWS offers, not Redis.
| gettodachoppa wrote:
| >We're all upset about this. Not because Redis deserves
| to get paid, it's that they acted like they were being
| good stewards of the open-source community and then they
| changed their mind.
|
| I'm an open-source zealot and I have no beef with the
| SSPL.
|
| Redis is still an open-source project for 99.99999999999%
| of entities on Earth. The only people crying foul about
| this are tech giants and the corporate drones at the OSI.
| Sorry if this sounds harsh, but normal people don't care
| about either of you.
|
| I'm not going to shed a tear for your trillion $ market
| cap company being asked to contribute a little more in
| exchange for all the wealth they siphon from the rest of
| the world.
|
| If the tech giant you're cheerleading for is such a fan
| of open-source, why don't they open-source the management
| layer like the SSPL asks? This would resolve this beef
| overnight, right?
| _msw_ wrote:
| The SSPLv1 has fatal flaws that were identified by the
| open source community during its review for OSI approval.
| Some of those flaws were attempted to be addressed in the
| SSPLv2 draft that was never finalized, which is an
| acknowledgment that the flaws exist.
|
| There isn't really any way for someone who wanted to
| offer software licensed under SSPLv1 to comply with the
| obligations of the license in good faith. This is what
| makes those obligations a "constructive restriction" [1].
|
| [1] https://meshedinsights.com/2021/01/27/all-open-
| source-licens...
| arp242 wrote:
| There are some conditions that don't fit with the OSD (in
| the view of some, opinions are divided). That's fine.
| It's allowed to have licenses that don't fit with the
| OSD. These licenses are not flawed in any objective
| sense.
| johnny22 wrote:
| The important thing here is that distributions are gonna
| start moving the packages to non-free repos or removing
| it altogether. So you'll have to get it as if were a
| closed source project anyways.
| LightFog wrote:
| Who is this 'we' - you are speaking about people who want
| the good bits of redis but not the responsibility of
| helping it sustain a business model built on open source?
| Your enabling of AWS's corporate FOSS-washing hasn't
| helped redis sustain the model you want it to.
| _msw_ wrote:
| There is no spin here. There are people that work for
| Amazon that work on FOSS projects out of the goodness of
| their heart, just like folks who are independent
| developers, or folks who work for startups, or folks who
| are just getting started.
|
| When a FOSS maintainer tells you they sometimes do work
| on the weekends for the love of the community [1] you
| believe them. The evidence (with timestamps!) is there
| for all to see in the pull requests and commit history.
|
| [1] https://twitter.com/reconditerose/status/177069731567
| 1535707
| LightFog wrote:
| Without denying the good intentions and inputs of the
| individuals going above and beyond to contribute - AWS as
| a whole contribute peanuts to these projects relative to
| what they make from them - they have it in their power to
| make these projects sustainable via healthy revenue
| sharing but don't.
| _msw_ wrote:
| You write as if you have all the facts, but I doubt you
| do.
|
| There are services with varying partnership terms, and
| there have been services launched with an intent to build
| long term mutually beneficial relationships that help
| ensure FOSS projects are well resourced.
|
| "AWS, working with Grafana Labs, will be contributing
| licensing revenue and code to help make Grafana even
| better, not just for the AWS service, but also for open
| source users and Grafana Cloud customers."
|
| https://aws.amazon.com/blogs/opensource/how-aws-and-
| grafana-...
| LightFog wrote:
| You are right - I don't have the details on Amazon's
| agreements with FOSS projects - have you made them
| public?
|
| All I have to go by are AWS's huge profits and the
| continuing struggles of FOSS projects involved with AWS
| to develop sustainable business models.
| cowsandmilk wrote:
| > make these projects sustainable
|
| You're just showing your ignorance of redis. The project
| is sustainable without the company as the vast majority
| of work on the project is done by those who don't work
| for the company.
|
| What isn't currently sustainable is the company. That's
| all.
| LightFog wrote:
| In that case you will have to excuse my conflating this
| special case with the multitude of other projects the
| same thing has happened to in the past and will likely
| continue happening to. I will watch with interest on how
| the contributors self-organise and prevent the exact same
| thing happening to whatever fork comes out.
| xuancanh wrote:
| I think the industry's criticism of AWS is
| understandable, msw. I believe it is time for AWS to come
| up with a more sustainable method to support the open-
| source community. By sustainable, I mean financial
| support and dedicated resources for contributing back to
| open source. Given your position, I hope you can initiate
| this type of change. Allocating 0.5 or 1% of AWS's
| revenue or even profit from each service that utilizes
| open-source software is unlikely to significantly affect
| the financial statements, yet it would represent a
| significant contribution to the open-source community.
| _msw_ wrote:
| We've done that. See one example in a sibling reply.
| Dylan16807 wrote:
| Having an example of doing that is great, but the comment
| said "each". For example, it matters if Redis got such an
| offer.
| arp242 wrote:
| Countering a criticism of how Amazon interacts with the
| projects it uses to drive a large section of its profit
| with "don't dimish the work FOSS maintainers!" absolutely
| is a spin. Or some other bad-faith behaviour. It sure as
| hell isn't a meaningful engagement with the core issues,
| is it?
|
| > There are people that work for Amazon that work on FOSS
| projects out of the goodness of their heart
|
| So they work for free then?
|
| Didn't think so.
|
| They just have a job they like. That's great. But lots of
| people have jobs they like. And lots of people work on
| weekends. But don't try to spin this as an act of
| altruism, because it's not.
| 8note wrote:
| Why pay redis though? Vs "the community"
|
| How much does redis pay those aws engineers for their
| contributions?
| reconditerose wrote:
| The beef I have here is that Redis also takes credit for
| community work. Most of the heavy lifting came from
| antirez, who created and ran the project up until 2020.
| (It's worth conceding that Redis did compensate antirez).
| At that time Redis created an open governing board that
| took over, with a majority of contributions coming from the
| community during this time (~25% of contributions came from
| Redis engineers, ~75% from the community, including ~3%
| that came from me personally). They own the trademark and
| the repository, so they can do what they want, but I take
| issue with the optics that this is really AWS or GCPs or
| some other vendors fault that Redis decided to blind side
| it's development community. Redis gave some of us a heads
| up this was happening, but most people are finding out by a
| blog post that Redis dissolved the previous open-governance
| (a fact they barely address in the blog post). We had to
| drop weeks of work on the floor because we could not longer
| finish it.
| klabb3 wrote:
| That's very interesting context and doesn't look too good
| on the "Redis governing board" indeed.
| _msw_ wrote:
| https://web.archive.org/web/20231030181609/https://redis.
| io/...
|
| (the page is now a 404) The core team has
| the following remit: * Managing the core Redis
| code and documentation * Managing new Redis
| releases * Maintaining a high-level technical
| direction/roadmap * Providing a fast response,
| including fixes/patches, to address security
| vulnerabilities and other major issues * Project
| governance decisions and changes * Coordination of
| Redis core with the rest of the Redis ecosystem *
| Managing the membership of the core team
|
| It seems clear to me (speaking only for myself) that the
| core team didn't have a say in project governance
| decisions and changes here. :-(
| throwaway290 wrote:
| If core team's pay depends on it maybe they did have a
| say... Developers also grow up and start families you
| know
| personjerry wrote:
| > But charity is not a sustainable business model
|
| Wasn't Dwarf Fortress charity funded for a long time?
| theshrike79 wrote:
| It was also just two guys with a moderate paycheck doing
| what they loved.
|
| They only hit it big when they got the game prettified
| and on Steam.
| personjerry wrote:
| Yeah but they got moderate paychecks for like a decade?
| Isn't that a "sustainable business model"?
| tayo42 wrote:
| The work was still on the behalf of AWS and their goal to
| make money and out compete Redis. it seems like this thread
| is forgetting that?
|
| The alternate future seems to be a headline like "Redis shuts
| down and stops development" anyway, so how is this different?
|
| What do you think Redis should do? Continue to let the cloud
| providers run them out of business? And all because Amazon
| was gracious enough to fund 1 employee working on it? I think
| this thread is missing that response.
| _msw_ wrote:
| No, the goal was to make Redis better for its community,
| which has positive downstream effects for everyone (users,
| Redis as a service providers-including Redis Ltd, etc.)
|
| And these efforts involved more than one developer. It is
| only that one of them happened to be a core team member
| (which required working in good faith for the interest of
| the Redis community as a whole--a "commitment to the
| project").
|
| https://redis.com/blog/redis-core-team-update/
| tayo42 wrote:
| You dodged the core part of my comment and question. Why?
|
| Amazon isn't running and charging for redis as a platform
| to make redis in the world a better place.
| _msw_ wrote:
| On the "downstream" side of this equation (managed
| services), the goal is to build a business that delights
| customers to the point where they part with their money
| to enjoy it. The ultimate goal there is naturally revenue
| and profit margin oriented, but _how_ you advance that
| goal matters a lot. In my experience, focusing on the
| customer first increases the chances of success.
|
| When such a line of business has a core component that is
| open source, the growth and health of the "upstream"
| project, its developers, and the user community is an
| essential component in its continued success. This is why
| folks on the ElastiCache team has been increasing their
| investments in both the upstream project code and in
| helping to maintain it as a "community-led" project under
| the previous governance structure.
|
| Those investments increased the provision of digital
| public goods (as open source licensed software is
| generally considered to be a "digital public good" even
| if it is not technically in the public domain).
| Increasing the provision of digital public goods is
| generally seen as in service of the public good, as it
| (more often than not) makes the world a better place.
| tayo42 wrote:
| I think I agree with someone else in this thread. This
| reads like spin and fluff. We all make quality
| improvements when we use open source software because we
| run into our own issues. Were also on a hacker forum, you
| don't need to respond to me like were at some business
| partner meeting.
|
| What do you want redis to do though as they are run out
| of business by amazon and the rest? Who pays for the rest
| of the developers?
|
| It reads like Amazon is trying to bully their code
| supplier. The code was out there, and without negotiating
| Amazon decided on their own "one developer sending TLS
| upstream seems fair". I'm sure amazon will negotiate with
| Redis for some amount in the end. Or have the one
| developer write the drop in replacement if the code is
| only worth one persons time and some other random
| commits? Then maybe Amazon can even open source it with
| no restrictions?
|
| Do you at least see and understand the perspective, that
| giant companies are making tons of money off software
| that is out there from smaller people. Giving back what
| is perceived not that much if anything?
| redwood wrote:
| This is like seeing an employee of Philip Morris pointing out
| that they have employees volunteer to tell kids how smoking
| is not healthy or like when British Petroleum funds research
| on green energy... I'm sorry but you're a cog in a machine
| which is fine but we have structural problems at play here
| that can't be swept under the rug
| ksec wrote:
| May be its time for people to look at memcached again. It is
| still actively maintained and last release was two days ago.
| stephenr wrote:
| Unfortunately memcached is missing some features that make
| Redis _very_ powerful for uses beyond a simple KV cache (for
| that simple cache usage neither are as important, granted):
|
| 1. Replication
|
| When using Redis for things like Session storage, a Job Queue,
| etc it's important that all hosts (web/app servers) see the
| same data, which means you either need them to all rely on one
| single server (which introduces a SPOF) or you need to be able
| to replicate the data, so that when the primary instance has an
| issue, a hot spare takes up the load with an existing dataset
| already in place.
|
| 2. Lua
|
| This is slightly less important, but it provides a lot of
| power: systems like Qless (https://github.com/seomoz/qless) use
| Lua to run a job queue that executes within Redis, so you get
| atomic writes for free, and you aren't tied to a specific
| application language to get a usable queue with consistent
| features/results.
| miraculixx wrote:
| Microsoft Garnet, licensed under MIT. Uses the same protocol
| meaning Redis client licenses still work.
| yjftsjthsd-h wrote:
| > 24. Will Redis accept community contributions under the new
| license?
|
| > Redis remains a proponent of the open source philosophy and
| maintains a large number of open source projects. For those who
| wish to contribute, we remain open to accepting future
| contributions - as we have done with our source available modules
| over the past five years.Going forward, acceptance of the
| contributor license agreement (CLA) by the contributor is
| necessary in order for us to consider the contribution.
|
| So they don't mind changing the license on their code, but they
| wouldn't want to have to be subject to the same terms from anyone
| else...
| justinclift wrote:
| Kind of a dupe of this:
| https://news.ycombinator.com/item?id=39772562
| ftyhbhyjnjk wrote:
| This is a good decision. Companies like amazon have a habit to
| rip everyone else.
| miraculixx wrote:
| Their Q&A essentially says you can no longer build anything that
| is commercial using Redis, except as a partner. That's exactly
| the opposite of what the SSPL License says.
|
| "this definition would include hosting or embedding Redis as part
| of a solution that is sold competitively"
|
| Sure this limits the condition to competing offerings. However in
| reality that's a huge stop sign. It essentially means "we'll get
| you" because whatever service/product you offer that somehow
| includes or so much as touches Redis they can always argue that
| you are effectively competing. That is they can always make the
| case that this would have been business to them if only.
| theshrike79 wrote:
| > "this definition would include hosting or embedding Redis as
| part of a solution that is sold competitively"
|
| I interpret this as "You can't sell Redis as a Service".
|
| You can make any number of applications that use Redis and host
| the instances yourself, you just can't package Redis and
| sell/rent a miraculixx-branded version of it.
| c0l0 wrote:
| I contributed a few LOC to Redis in the past (before "Redis Labs"
| had taken over), but never signed a CLA or assigned Copyright
| (that's not even possible in my country of origin). I realize
| that under the permissive license that I published my
| contributions under, they can very well do what they are doing.
| That they are doing it, is disappointing nonetheless. I guess
| there are more people like me out there, with vastly more
| important contributions, who feel about the same. I, for one,
| will not contribute to the project under this new license any
| more.
|
| What a shame.
| lawik wrote:
| So the technical founders of both Redis and Hashicorp managed to
| step down before their respective businesses take on a shitstorm
| by steering away from FOSS. Unless I have my timelines wrong.
|
| I wonder if they knew that was coming and disagreed. Or knew it
| was coming and didn't want to take the hit to their reputation.
| Agree or not with the move, there is a reputation hit. Or was it
| them leaving that enabled the change to be pushed through?
|
| This is entirely speculation and just something I noticed with
| Hashi and now see repeat with Redis.
| stephenr wrote:
| > knew that was coming and disagreed. Or knew it was coming and
| didn't want to take the hit to their reputation
|
| Or had enough sway to prevent it happening before they left?
|
| > just something I noticed with Hashi and now see repeat with
| Redis
|
| The similarity wasn't lost on me either.
| mort96 wrote:
| Alternative title: Redis is no longer open source but rather
| source available.
| nailer wrote:
| Not sure why this is downvoted, it's accurate.
| efilife wrote:
| Aren't those two interchangeable?
| bawolff wrote:
| No
| darby_eight wrote:
| They are. The change is that the source is no longer (as?)
| free.
| speedgoose wrote:
| No really. Many proprietary software are source available but
| far from being open source.
|
| Even Microsoft Windows is source available if you are an
| important customer: https://www.microsoft.com/en-
| us/sharedsource/default.aspx
|
| A bit more public and open to anyone is Unreal Engine's
| source code: https://dev.epicgames.com/documentation/en-
| us/unreal-engine/...
| nicce wrote:
| That Windows page seems to be from 2015. Wonder if that
| still applies.
| my123 wrote:
| Yes, it does still apply
| gcau wrote:
| To a lot of people (if not the majority outside hacker-news),
| yes.
| mort96 wrote:
| Why is the opinion of people unfamiliar with the field of
| programming (i.e the majority outside hacker news)
| interesting?
| cthalupa wrote:
| Nope. This is tied to the whole "Free as in speech, not beer"
| thing.
|
| Open Source has core definitions around the freedoms (the
| "speech") allowed to people when making use of that source
| code.
|
| Source available makes the source code available for free
| (the "beer") along with certain specific freedoms, but not
| all of the freedoms that would be required to be Open Source.
|
| Whether or not you think those missing freedoms are important
| is a matter of personal opinion, I suppose. I think they are,
| which is why I try to avoid source available software if
| there is a reasonable open source alternative.
| kelnos wrote:
| Source available need not be free as in beer, though. A
| company can charge for it, and of course restrict
| distribution.
| cthalupa wrote:
| Very true. I suppose I should have clarified that source
| available in the context of a lot of these formerly open
| source projects, and not as a blanket term.
| byyll wrote:
| Yes, except some people are trying to redefine English. Open
| source means the source is open - you can see it.
| jpfr wrote:
| And this is why it is a bad idea for open source contributors to
| transfer their copyright.
|
| If hundreds of commits are baked into a software - under an open
| source license but without the full copyright transferred to a
| central legal entity - then it becomes impossible to change the
| license post-hoc.
| wizzwizz4 wrote:
| This is true for copyleft licenses, but not for permissive
| licenses. And you can still get a copy of the old version under
| the old license from someone who downloaded it before the
| license change.
| _msw_ wrote:
| That may be true if a codebase is licensed under the GPL and
| has a diverse copyright ownership. But the 3 clause BSD is not
| that.
|
| 3 clause BSD gives everyone permission to use it in new works
| that are made available using license terms of one's own
| choosing, so long as the obligations of those 3 clauses
| continue to be met.
| jpfr wrote:
| > 3 clause BSD gives everyone permission to use it in new
| works that are made available using license terms of one's
| own choosing, so long as the obligations of those 3 clauses
| continue to be met.
|
| But what I get from this is: The project switched away from 3
| clause BSD to something that is _less permissive_.
| _msw_ wrote:
| The 3 clause BSD gives all the permissions that are needed
| for someone to add restrictions via their own license
| terms.
|
| Licenses like the GPL come with an obligation that one
| _not_ add restrictions when passing the software on to
| others.
| jaypatelani wrote:
| So how did RedHat add restrictions on gpl code base of
| CentOS?
| Vinnl wrote:
| But the less permissive licence effectively only applies to
| new modifications to the (contributed) code, which is
| allowed by BSD, but not by GPL.
| eadmund wrote:
| When will developers learn that the BSD _does not protect you
| or your users_? I understand the philosophical reasons some
| folks like BSD /MIT-style licenses, but at the end of the day
| they are not much more than public domain: anyone can take
| someone's work and contributions, make improvements and keep
| the entire thing -- original work and contributions, as well
| as improvements -- proprietary.
|
| If you care about a software commons, if you care about
| benefiting from the improvements others make to your own
| software, if you care about your users benefiting from the
| improvements others make: use a copyleft license!
| jillesvangurp wrote:
| I'm assuming people are forking this as we speak. Kind of sad to
| see companies cut themselves off from their own developer
| communities.
|
| I understand why they do it. I just don't agree it works long
| term.
|
| Most Redis users have never paid the company behind it even a
| single cent. Me included. So, I can appreciate them doing this in
| order to make some money. Except it won't change my behavior;
| I'll just use the fork. Just like the vast majority of other
| Redis users, external Redis contributors, all of the cloud
| providers currently offering Redis commercially, and by the time
| this runs it course probably a fair bit of current Redis
| employees.
|
| Given the large amount of commercial users and cloud providers
| offering Redis, I don't think it will take long for them to get
| organized even. They pretty much have to given that they have
| lots of users paying them for this.
|
| There are some precedents with Terraform, Elasticsearch, Red Hat,
| and a few other big players now dealing with a lot of their
| target users and potential customers depending on open source
| forks. As a business strategy alienating future users like that
| seems misguided.
|
| When Oracle took ownership of Sun's open source projects
| (including such things as mysql, hudson, openoffice, etc.), they
| quickly lost control of most of that. Oracle's attempts to
| convince the world to use their closed source offerings never
| amounted to much. Even with Java, they more or less gave in and
| openjdk is where the action is these days. Except for a few
| banks, very few people use the Oracle JDK. There's no need,
| Oracle has long ago stopped pretending there's any advantage to
| that. All the development happens on OpenJDK. There are half a
| dozen different companies offering certified builds.
|
| Anecdotically, I consult on Elasticsearch and Opensearch. Most of
| my recent clients default to Opensearch. It's just the way it is.
| They all go for the free and open source option.
|
| The point here is that this can only end in one way: the creation
| of a Redis fork that will be used by the vast majority of current
| Redis users.
| pjmlp wrote:
| I see it ending in another way, long term FOSS will be
| considered a phase in the industry, never to be repeated again,
| as the industry settles back on trial and demo versions,
| without full features available on the free tier/source code.
| stephenr wrote:
| That might make sense if the tools in question were _created_
| by corporations who used OSS as a pseudo demo.
|
| Redis the project/tool existed long before Redis the company
| owned it.
|
| Vagrant existed before HashiCorp owned it.
|
| Significantly: both companies dropped permissive licensing
| _after_ the creator of their (original) products stepped
| away, and both are venture capital backed companies.
|
| So we could just as easily say "I see that long term people
| will _preemptively_ fork projects the moment they are owned
| by a VC backed company "
| pjmlp wrote:
| Which many developers only adopted, because they didn't had
| to pay anything, while the tool maker's salaries were being
| burned by VC money.
| stephenr wrote:
| > because they didn't had to pay anything, while the tool
| maker's salaries were being burned by VC money
|
| I think you somehow missed the point where Redis the
| project existed and was extremely popular _before_ it was
| owned by what is now Redis the company.
|
| The competition for redis in the early days wasn't paid
| alternatives, it was other _open source_ alternatives;
| Redis just provided a more featured solution.
| pjmlp wrote:
| Which people adopting Redis didn't had to pay for, if
| they had to, they would rather suffer with those other
| less capable open source alternatives instead.
| stephenr wrote:
| The point is that it wasn't developed by VC money. It was
| _bought_ with VC money after the fact.
|
| It wasn't a "demo" for a paid product funded by corporate
| dollars or VC funding, it was just a thing that someone
| created, and released as an open source project.
|
| It's hilarious that you think the companies dropping open
| source licenses for the products they _bought_ are going
| to stop the industry using open source. As I said
| originally, it 's going to have the opposite affect: it's
| going to make the industry embrace the very nature of
| open source and create forks of projects, the moment
| there's a sniff of a corporate buy out, specifically
| because of this type of activity.
| pjmlp wrote:
| Dreamers will be dreamers.
|
| The ongoing uptake in open core, shows where it goes.
| ghjm wrote:
| The question here is what motivates individual developers
| to write big projects and then release them as open
| source. I think vague dreams of million-dollar deals are
| part of this for a lot of people. As the developer
| community becomes more aware of what a grind open source
| maintainership is, people are already less interested in
| taking on that responsibility. If we also prevent big
| money buyouts from happening, I wonder what's left to
| motivate a future developer to create the next redis.
| stephenr wrote:
| Redis was created for the same reason most of us create
| open source tools: to scratch an itch, to solve a problem
| (or improve a solution).
|
| I find it hard to believe many if any would see "create
| an open source tool" as a method to become a millionaire.
| eadmund wrote:
| Free software existed long before mass investment by VCs.
| The business arguments for open source existed long
| before the low-interest-rate period.
|
| We are probably not going to see mass investment by VCs
| in free software for awhile (perhaps never, but that is
| pretty strong), but developers will keep scratching our
| itch.
|
| And maybe more and more developers and users will realise
| that AGPL/GPL/LGP are the only licenses which truly
| protect one's software.
| stephenr wrote:
| > maybe more and more developers and users will realise
| that AGPL/GPL/LGP are the only licenses which truly
| protect one's software.
|
| I don't think this is a fair assessment of the cause of
| the issue with redis, or hashicorp, or elasticsearch etc;
|
| This wasn't some nefarious third party taking all the
| community good will and contributions and creating a
| private fork to kill the original projects.
|
| If you don't want some corporate asshole to turn your
| open source project into a get rich quick scheme, don't
| give control of your project to that asshole.
| snapplebobapple wrote:
| We basically need to see the big users of these projects
| hiring staff to contribute to the fork and destroying the
| original project for that to work well i think. We need to
| invalidate the business model of "buy opensource project,
| be a giant asshole" by causing billions of losses t( vcs
| and proving there is no mote like there can be buying
| closed source before thia bs goes away.
| bluGill wrote:
| We need to normalize the idea that if a company uses
| something open source they automatically get someone to
| contribute to the project. That couple be hiring people
| in house to maintain it, it could be paying a consultant,
| it could be donating to a charity that maintains it.
| Probably some other way as well. However if you are a
| company getting value from open source you really need to
| put some money into keeping it maintained.
|
| The above applies to private people as well. You use how
| many different pieces of software, what are you doing to
| ensure they stay maintained. (if you are like most
| nothing...)
| lethedata wrote:
| I think it comes down to is the project there to make money
| or not. If it's mainly for money then it would never start
| out open source (ie AWS) but if it's a solution to a problem
| that can be improved via collaboration then it'll be Open
| Source (ie OpenStack). This hasn't really changed over the
| years.
|
| What we are seeing here, as others have pointed out, is that
| companies are buying Open Source solutions and then close
| sourcing them because they view it as a money maker which in
| the end leads to forks.
| thrdbndndn wrote:
| And Redis as a company can get some cash from certain amount of
| clients that decided to stick with Redis (even in Oracle's
| case, this was a non-trivial amount of money)?
|
| It sounds like a win-win to me.
| throwaw12 wrote:
| > I'll just use the fork
|
| For personal projects maybe yes, doesn't work for companies,
| they can't chase for thousand different forks of Redis and try
| to understand why feature isn't working properly on their
| version. Unless single fork emerges as a winner
| jillesvangurp wrote:
| Why would there be thousands of forks? We only need one good
| one.
|
| I'm predicting such a fork backed by several core committers,
| and possible several cloud providers will emerge pretty
| quickly because they all need this to continue to exist as
| free and open source. AWS is not going to pay Redis a cent.
| Nor is Azure. Or Google. Or people commercializing open
| stack. All of those offer Redis support currently. Lots of
| their users use it.
| lethedata wrote:
| I think the long term game works if you look at it from a
| Broadcom style prospective. You're not looking to snag many
| users but rather the few very expensive ones who have built
| themselves around the product. From the Businesses prospective
| they'll pay the increased prices to avoid moving completely or
| in the short term during migrations.
|
| To avoid the short term, providers could "buy time" and keep
| prices low until the project deviates far enough from forks,
| making migration much harder, then increase prices.
|
| Either way, long term they can end up with a lot of money from
| a few companies rather than continuing to support many mixed
| sized companies.
|
| I don't like it either but I can see it working.
| ethbr1 wrote:
| The reason this inevitably faceplants is lack of access to
| real user feedback.
|
| Invariably, someone looks at the numbers and realizes "We
| could make way more money if we only catered to the top 2% of
| our customers!"
|
| Unfortunately, opinions and needs of the top 2% of customers
| != a generally useful product.
|
| Thus, the reason to try and maintain user volume is better
| product-market feedback to guide development, instead of
| revenue.
| crote wrote:
| Do those users actually exist, thought?
|
| Broadcom is able to screw over its customers because they
| have to choose between either reworking a core part of their
| infrastructure, running legacy code without support (provided
| you have a perpetual license), or paying a huge license fee.
| With Redis, the current version is already open-source: you
| can maintain it yourself, switch to a drop-in replacement
| community fork, or pay one of the dozens of SaaS companies to
| run it for you. Switching away from the official Redis flavor
| can be as simple as a one-line change in your infrastructure
| recipe. If they increase their prices, why would anyone stay?
|
| I think MySQL is probably a better comparison. After Oracle's
| acquisition they have been trying quite hard to add vendor
| lock-in and extract money out of it, but these days MariaDB
| has essentially made it completely irrelevant. I wouldn't be
| surprised if the future of Redis looked quite similar.
| lamontcg wrote:
| > Most Redis users have never paid the company behind it even a
| single cent. Me included. So, I can appreciate them doing this
| in order to make some money. Except it won't change my
| behavior; I'll just use the fork.
|
| Do you not see how incredibly entitled this is?
|
| If everyone does this then there's no money to maintain the
| fork, and you're looking for slaves to run it. Or else
| everything FOSS just gets maintained by employees at massive
| tech companies that have other businesses which fund it.
| api wrote:
| This is the issue: FOSS has largely become free labor for
| SaaS companies.
| smokel wrote:
| It is, however, also incredibly realistic.
|
| People are not using open source for the hippie philosophy.
| They are using it because it is free (as in beer), but even
| more importantly: they are using it because non-free licenses
| are a terrible pain in the ass.
|
| Legal aspects are a headache, and the amount of effort to get
| someone in your company to pay even a tiny amount for some
| library or service is a serious hurdle.
|
| I would not be surprised if adopting a non-free library would
| take a typical company ~40 man hours of work. At current
| rates, that translates to quite an expensive license.
| bluGill wrote:
| Just getting open source adopted in my company takes around
| 10 man hours, and that is for something like a compiler
| that is only for internal use. If we will ship/expose it to
| customers we do due dalliance that probably amounts to 40+
| man-hours to verify we can accept the license terms for
| that use and that the project doesn't have some hidden
| license issue (someone copied in code with a different
| license, link to something with a different license...).
|
| Getting close source is even more work though - now we need
| someone to negotiate license terms (that is make sure our
| proposed use is compatible with the license we buy). We
| also make sure there is no risk of using their code (what
| if the closed source binary library has some AGPL3 code in
| it). I'm not even sure how to go through that process.
| api wrote:
| That may be true, but a lot of the _creators_ of open
| source do in fact do it for the "hippie philosophy." That
| disconnect will eventually kill it. Why work hard to just
| be free labor for SaaS companies and people who don't care
| about you?
| baggy_trough wrote:
| Your use of "slaves" is a remarkably offensive way to
| describe volunteer software developers.
| indymike wrote:
| > Do you not see how incredibly entitled this is?
|
| No. I think part of the value of Redis to date was exactly
| that it was BSD licensed. When I started using it, I showed
| many other developers what they could do with it, and those
| devs took Redis to work, and built products and some bought
| services/products from Redis. Without the open source
| product, Redis the company would likely not exist as it does
| today. Times change, and the right strategy for Redis the
| company probably looks a lot different than when they started
| it on the back of Antirez's still awesome software.
| volongoto wrote:
| Microsoft introduced an almost drop in replacement 3 days
| ago[1]. It is claimed to work with most Redis clients. I
| believe this will change things quite a bit a least for Azure
| users.
|
| [1] https://www.microsoft.com/en-us/research/blog/introducing-
| ga...
| CyanLite2 wrote:
| Looks neat, but probably only for internal MSFT usage.
|
| For what it's worth... Microsoft was quoted in the Redis
| press release as a cloud provider that has partnered
| officially with Redis under this new licensing scheme.
| Shakahs wrote:
| Beyond forks, at this point Redis is an API target that has
| been implemented by other databases (Dragonfly, Upstash, AWS
| ElastiCache Serverless).
| WhyNotHugo wrote:
| There is a work-in-progress fork here already:
| https://codeberg.org/redict/redict
| miraculixx wrote:
| > Most Redis users have never paid the company behind it even a
| single cent. Me included.
|
| Most users never will. That's the fallacy made by MBA types.
| They dream up some lofty sums "if only everyone paid us money".
| What they don't realize is that most users will find
| alternatives.
| pizza234 wrote:
| Interestingly, there is some nuance. One of the two licenses
| seems to be copyleft, but it's just not currently approved.
|
| EDIT: Ironically, the SSPL seems to be more open than the
| copyleft counterpart (AGPL) - the difference is that it enforces
| releasing the whole service source. Any discussion assuming that
| the new dual licensing model is hurting the users' freed is
| actually unfounded.
|
| ---
|
| About SSPL (https://redis.com/legal/licenses):
|
| SSPL is a source-available license created by MongoDB, who set
| out to craft a license that embodied the ideals of open source,
| allowing free and unrestricted use, modification, and
| redistribution, with the simple requirement that if you provide
| the product as a service to others, you must also publicly
| release any modifications as well as the source code of your
| management layers under SSPL.
|
| SSPL is based on GPLv3, and is considered a copyleft license.
| This means that if you use the source code and create derivative
| works, those derivative works must also be licensed under SSPL
| and released publicly. For more information, MongoDB has a good
| FAQ.
|
| Note that SSPL has not been approved by the OSI, and we do not
| refer to it as an Open Source license.
| Macha wrote:
| > but it's just not currently approved:
|
| This makes it sound like it's just a matter of resources or
| time to just get it approved, which is misleading. Field of use
| restrictions go against most definitions of open source or free
| software, and it was on track to be rejected by OSI until they
| withdrew from the process.
|
| https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
|
| Similarly, Debian also rejected classifying it as open.
| aragilar wrote:
| Both were noped by lawyers pretty quickly (who actually know
| their stuff and how licences work, rather than random
| engineers), so I'm not sure what you are trying to suggest...
| imranhou wrote:
| Is this going the way of elastic and aimed at service providers
| like AWS using it without paying for it?
| ilaksh wrote:
| They have something called MemoryDB. I wonder if that is
| basically an integration of Redis Cluster into AWS.
| Gasp0de wrote:
| Yes it is, as well as ElastiCache
| ZiiS wrote:
| https://aws.amazon.com/elasticache/
| lionkor wrote:
| Will have to find an alternative that can work with sentry to eat
| 150 GB of RAM for no reason /s
| figmert wrote:
| I don't know which part of your comment you're saying
| sarcastically, but I presume you're referencing the fact that
| Redis uses up a lot of memory.
|
| This is because Redis is a caching database, and pulls the data
| into memory for it to be faster. This is by design.
| cthalupa wrote:
| I believe the sarcasm is around Sentry and implying that it's
| redis usage is poorly optimized. I'm not familiar with
| Sentry, but it looks like the self hosted version makes use
| of redis as part of it's underlying stack.
| the_mitsuhiko wrote:
| I recognize our (Sentry's) over-use of redis. Also doesn't make
| us particularly happy. Can't promise that this will get
| significantly better but the desire is there at the very least.
| stees wrote:
| KeyDB? :)
| Comma2976 wrote:
| Just run a few instances of any JVM application
| kristopolous wrote:
| I never went to law school. Can someone explain this?
| Raed667 wrote:
| aws and every other cloud provider is selling hosted redis and
| making money.
|
| redis the company, wants a part of that pie.
| Ekaros wrote:
| So it seems making money by developing open source products is
| hard. I wonder how many more we will see this and next year? And
| is the open source model actually broken outside hobbyist and
| large enough projects with enough players like Linux...
| rwmj wrote:
| Or it works just fine. I imagine that Redis would be OK if it
| was just a small company with a few consulting developers.
| Expecting to build a huge business around it with y-o-y
| increasing shareholder returns only works for a very very few
| companies.
| rwmj wrote:
| It seems that the new license (SSPL) is probably not open source
| because of (at least) field of use restrictions:
| https://opensource.stackexchange.com/questions/7522/sspl-and...
| https://opensource.org/blog/the-sspl-is-not-an-open-source-l...
| dzogchen wrote:
| Probably? It is a non-free license plain and simple.
| rwmj wrote:
| Yes you're right, this is the opinion from Fedora's legal
| counsel: https://lists.fedoraproject.org/archives/list/devel@
| lists.fe...
| Takennickname wrote:
| Is that similar to Red Hats legal counsel?
| warp wrote:
| Yes, Richard Fontana is Red Hat's open source lawyer.
| rwmj wrote:
| Richard Fontana is also Red Hat's legal counsel yes.
| https://en.wikipedia.org/wiki/Richard_Fontana
| Macha wrote:
| Debian too: https://bugs.debian.org/cgi-
| bin/bugreport.cgi?bug=915537#15
| sofixa wrote:
| IMO we need new terms for that kind of stuff. New licenses such
| as SSPL, BSL FSL are becoming more and more popular, and _for
| very good reason_ (the conditions today are vastly different
| than they were 20 years ago when there was no AWS to resell
| your FOSS to the whole world). They are not "open source"
| because of the restrictions, but the next closest term that can
| be applied to them is "source available" which means something
| different - source code is technically there, eventually, and
| is not reflective of the reality of those relicensed projects.
| ElasticSearch, Sentry, etc. are still developed in the open,
| random people not affiliated with the project can still submit
| PRs, and anyone not trying to compete publicly with the company
| behind the project can still do whatever they want.
| ShaneCurcuru wrote:
| Apparently marketing people who want to sell stuff under
| those new licenses think "source available" is uncool.
|
| Some folks are working on terminology over here, if you're
| curious.
|
| https://github.com/softwarecommons/softwarecommons.com/issue.
| ..
| sofixa wrote:
| > Apparently marketing people who want to sell stuff under
| those new licenses think "source available" is uncool.
|
| It's not that it's uncool, it's just not true and
| reflective of reality. There's a world of difference
| between a .zip on an FTP ("source available because GPL
| says it must be") and everything still happening in public
| on GitHub and everyone still being able to contribute if
| they want to. Both are technically "source available".
| dragonwriter wrote:
| "Source available" is uncool, compared to "open source" or
| "Free Software", in substance, not uncool _as a term_.
|
| The non-ideological value of open source is exactly the
| commodification that the retreat to source available
| licensing seeks to end, along with downstream consequences
| of that commodification.
|
| It is not a problem of terminology.
| dragonwriter wrote:
| > the conditions today are vastly different than they were 20
| years ago when there was no AWS to resell your FOSS to the
| whole world
|
| No, its not. SaaS has existed for more than 20 years and
| reselling FOSS has been something it has done as long as
| there has been FOSS to resell.
|
| What's changed recently is people launching venture-funded
| startups centered on gaining popularity through the appeal of
| FOSS with initially no clear monetization plan or one
| centered on selling services that were essentially just the
| FOSS, hosted. _That's_ the new thing, and why there is so
| much energy going into trying to figure out how to retain the
| marketing appeal of FOSS with the new licenses that lack the
| value proposition of FOSS.
| bluGill wrote:
| > What's changed recently is people launching venture-
| funded startups centered on gaining popularity through the
| appeal of FOSS with initially no clear monetization plan or
| one centered on selling services that were essentially just
| the FOSS, hosted. That's the new thing,
|
| That isn't new either. What has changed is some have found
| what looks like a path to monetization that seems like it
| might actually work. 20 years ago they never found a path
| to monetization at all. You just forgot about the other
| failed ones because they never went anywhere (though the
| source code may still be out there).
| ShaneCurcuru wrote:
| SSPL is definitely not open source, it violates #6:
|
| https://opensource.org/definition-annotated#6
|
| That's the point of open source, and free software in a way as
| well. Copyleft licenses have restrictions, but as long as you
| follow those restrictions, you can build whatever you want
| using the software. SSPL, FSL, BUSL licenses outright prevent
| you from competing in certain commercial ways, no matter what.
|
| Just because most business models don't _want_ to comply with
| copyleft doesn 't mean it's not open source - it just means it
| doesn't fit your business model.
| bit_flipper wrote:
| You can also build whatever you want with SSPL, as long as
| absolutely everything you use to run a service that supports
| it is also licensed as SSPL. It's not that different from the
| AGPL in spirit.
| nicce wrote:
| At the same time Microsoft releases Garnet:
| https://github.com/microsoft/garnet
|
| Good timing.
| wg0 wrote:
| Why would they write such a critical piece of software in C# or
| Java for that matter what requires a whole runtime + VM
| installed.
| fabian2k wrote:
| Why not?
|
| And .NET can bundle the runtime, even in a single binary if
| you prefer that.
| _wolfie_ wrote:
| > Why not?
|
| The bootstrapping path does not exist. There is (afaik) no
| way to go from C compiler to working dotnet environment.
| You are supposed to just download binary blobs from m$soft.
| neonsunset wrote:
| https://github.com/dotnet/dotnet exists for "complete"
| source build that stitches together SDK, Roslyn, runtime
| and other dependencies. In fact, it is required by
| certain Linux distributions for publishing in their
| feeds, to be built from source in full. All components
| above can be built and used individually (usually), which
| is what contributors also do. For example, you can clone
| and build https://github.com/dotnet/runtime and use the
| produced artifacts to execute .NET assemblies or build
| .NET binaries.
| nicce wrote:
| And yet the benchmarks are better than C or C++ alternatives,
| somehow.
| GordonS wrote:
| I don't think this is an issue. You can bundle a stripped
| down runtime with C# binaries. If you want, you can even
| build it all into a single binary.
| highwaylights wrote:
| ???
|
| The JVM and the .NET clr are just runtime JIT engines. It's
| not like they ship with a full O/S and a hypervisor.
| SSLy wrote:
| VM is an overloaded term, it both means virtual computers
| that run some OS kernels, and runtime that runs some
| usually* user-space code.
|
| * compare with eBPF
| wg0 wrote:
| It is not about the hypervisor but a solution that pitches
| itself as a memory cache relies on GC is the main thing I
| am pointing out.
|
| Rust would have been a better choice.
| ryanjshaw wrote:
| You're behind the times:
|
| > Publishing your app as Native AOT produces an app that's
| self-contained and that has been ahead-of-time (AOT) compiled
| to native code. Native AOT apps have faster startup time and
| smaller memory footprints. These apps can run on machines
| that don't have the .NET runtime installed.
|
| https://learn.microsoft.com/en-
| us/dotnet/core/deploying/nati...
|
| While there are limitations, this is an active area of work
| for future versions of .NET.
| wg0 wrote:
| This is the best case scenario and lots of stuff would be
| left out, you can't use all of the APIs as is noted in the
| documentation.
| neonsunset wrote:
| Garnet doesn't use those however. A lot of older
| libraries that do runtime code emit or _unbound_
| reflection don't work, but a lot of others do even though
| they were written more than 10 years ago and were adapted
| to netstandard2.0 target. Either way it does not benefit
| much from NativeAOT given it's expected to be long-
| running where JIT is more advantageous.
| piaste wrote:
| You can still use a lot more APIs from AOT C# than from
| C/C++/Zig/Rust :)
| egorfine wrote:
| At this point C# little to nothing common with Java and
| builds a perfectly runnable binaries. C# is extremely capable
| and strong and arguably is one of the best dev platforms
| there is.
|
| (On the other hand, call me an old fart, but my trust in
| Microsoft has been completely eroded in early millennium and
| did not came back.)
| taspeotis wrote:
| Because C# is a nice language that can be fast and C++ is a
| shit language that can be fast.
| blackoil wrote:
| Is it a research product or for production?
| jiripospisil wrote:
| > Note that Garnet is a research project from Microsoft
| Research, and the project should be treated as such. That
| said, we are bunch of highly passionate researchers and
| developers working on it full-time at the moment to make it
| as stable and efficient as we can. Our goal is to create a
| vibrant community around Garnet. In fact, Garnet has been of
| sufficiently high quality that several first-party and
| platform teams at Microsoft have deployed versions of Garnet
| internally for many months now.
|
| https://microsoft.github.io/garnet/docs
| darkwater wrote:
| Well, Microsoft and Azure seems to be fully on-board with this
| change: https://azure.microsoft.com/en-us/blog/redis-license-
| update-...
| zozbot234 wrote:
| Well yes, what else would you expect from the folks who once
| called open source "a cancer" and came up with "SharedSource"
| as a replacement. Good move on releasing a genuinely open
| alternative, though.
| bayindirh wrote:
| MIT allows for Microsoft's "our very slightly internally
| changed version does behave slightly differently enough so
| the two can't interoperate" shenanigans, though.
| petepete wrote:
| > This dual-license model provides greater clarity and
| flexibility, empowering developers to make informed decisions
| about how they utilize Redis technologies in their projects.
|
| Yeah sure.
| jsmeaton wrote:
| Fully on board, but no mention if they'll be releasing the
| source used to run Redis on Azure. Do they have an exemption?
| A separate license?
|
| On one hand I could see why Microsoft would back the original
| project, since they likely don't want Amazon owning a
| replacement (elasticsearch). But I'm not sure how they plan
| to honour the new licensing?
| jsmeaton wrote:
| Ahh - side deal licensing.
|
| "Redis will continue to support its vast partner ecosystem
| - including managed service providers and system
| integrators - with exclusive access to all future releases,
| updates, and features developed and delivered by Redis
| through its Partner Program. There is no change for
| existing Redis Enterprise customers."
|
| I wonder how exclusive this actually is. Did Microsoft pay
| a boat load of money to freeze out Amazon?
| joking wrote:
| I think that is more that Amazon doesn't want to pay to
| support anything, and that includes Redis, so I don't
| think Microsoft paid for an exclusive deal.
| justsid wrote:
| And in the HN discussion about Garnet, someone said they'd
| never go into bed with MS. Their argument was that MS is just
| going to do bait and switch and will just change the license
| when it suits them, therefore Redis is superior because they
| will always be open source licensed. What a prediction.
| arp242 wrote:
| Garnet is a small side-project for Microsoft, that they can
| fund with loose change Microsoft finds in the sofa. Redis on
| the other hand is the bread and butter for Redis.
|
| There's a lot less incentive for Microsoft to muck about with
| the license and in that sense it's not really about trust.
| wg0 wrote:
| Another wonderful piece of open source software swallowed by
| corporate warlords. Now expecting an OpenRedis fork soon from
| AWS?
| mirekrusin wrote:
| It's the other way around. Mega corps are cut off from leeching
| on open work.
|
| It's the only sustainable way to have business model around
| open work.
|
| With pure open source licensing you have asymmetry - where a)
| you guys implement it b) we sell it, thanks - problem. You
| cannot run sustainable business around it.
|
| As far as I understand it they want to preserve "open
| sourceness" for self hosted projects - ie. if you run redis in
| your docker/vm/k8s, you're fine. But if mega corp clouds are
| offering managed service, they need to give back a cut from
| premium they're charging end users.
| Abroszka wrote:
| > As far as I understand it they want to preserve "open
| sourceness" for self hosted projects - ie. if you run redis
| in your docker/vm/k8s, you're fine. But if mega corp clouds
| are offering managed service, they need to give back a cut
| from premium they're charging end users.
|
| I like it and I think this is how open source should work to
| thrive.
| cthalupa wrote:
| The world would be a very different place if, say, the
| people that wrote apache httpd felt this way.
|
| I don't know what it would look like, so I won't weigh in
| on whether or not it would be a good or a bad thing. But it
| would assuredly be different.
| afiori wrote:
| If a webserver were to use this license it would still
| allow most enterprises to use it as a web server (IIUC)
| except if you are offering an open proxy service.
|
| All websites and even value-add proxies likely would not
| be impacted
| cthalupa wrote:
| I think you're underestimating the impact that the
| webhosting industry had on the popularity of Apache
| httpd, all of these related ecosystem projects like PHP,
| MySQL, etc., and even Linux itself. How many small
| businesses launched because cheap and good webhosting was
| plentiful? How many developers cut their teeth making web
| apps that worked on the average cPanel/WHM webhosting
| provider? The answer to both of these is "A lot. A whole
| lot."
|
| The butterfly effect would be massive.
| wg0 wrote:
| by corporate warlords I mean - the ones leeching off the open
| source work. :)
| bogantech wrote:
| Nevertheless the leeches will start a big PR campaign about
| how the creators are evil for wanting a piece of the pie just
| like they did for Terraform
| jeltz wrote:
| Redis is also on the the leeches in this case. They have a
| 500 people company which plans to profit off of hosting
| Redis and wants to have a competitive advantage by being
| the only ones who do not have to open source their
| modifications.
| ncruces wrote:
| But now you're open to [Redis] taking you to court saying
| that your service that _uses_ [Redis] is too similar to "just
| [Redis]" for you to offer it to anyone else.
|
| Field of use restrictions are a terrible idea, and totally
| incompatible with "open sourceness".
| stavros wrote:
| Can someone please explain why this is bad to me or my company,
| who don't offer a paid, hosted Redis installation? As far as I
| can see, this license means that Redis the company gets some
| exclusivity on who can run a hosted version of their product, and
| everybody else gets it for gratis, with source we can change
| libre.
| bawolff wrote:
| Its no longer open source, if being open source isn't one of
| your requirements then it probably doesn't directly effect you.
|
| It might indirectly effect you as some free labour from the
| open source community might dry up. E.g. your linux distro
| might no longer package it and you might have to rely on
| packages maintained by redis which might not be as well
| integrated into your distro (although lots of users probably
| don't care about that)
| ForHackernews wrote:
| "open source" has always been a marketing term. It doesn't
| mean anything because it's never meant anything.
|
| The GNU people fought the good fight on free/libre software,
| but they lost because companies are greedy and devs are lazy
| at their day jobs.
| bawolff wrote:
| The people who coined the term (OSI) gave a definition when
| they coined the term. That definition is almost universally
| accepted in the software world. Redis no longer meets that
| definition.
|
| Just because something is a marketing term doesn't mean its
| meaningless. You can't sell non free range eggs as "free
| range" simply because its a marketing term. Etc
| jen20 wrote:
| The term "free range" is almost meaningless when buying
| eggs - even the opening paragraph of Wikipedia explains
| this:
|
| "Free-range eggs are eggs produced from birds that may be
| permitted outdoors. The term "free-range" may be used
| differently depending on the country and the relevant
| laws, and is not regulated in many areas."
|
| Bad choice of example!
| JackSlateur wrote:
| It is far from a marketing term : opensources products can
| be used without talking to legal departements.
|
| For big compagnies, this a game-changer because you can
| spare yourself months of "work".
| kelnos wrote:
| > _opensources products can be used without talking to
| legal departements._
|
| Pretty much every company I've worked at has wanted legal
| signoff for use of any open source project. Granted,
| compliance with that directive was often spotty. But some
| did have a tool to scan our repositories for
| dependencies, and flag things that had licenses not on an
| approved list (which, no, was not the entirety of OSI-
| approved licenses).
| jen20 wrote:
| AGPL is an "open source" license per OSI - I assure you
| if you use code licensed under it at many big companies,
| you might avoid a meeting with legal but will instead get
| one with HR...
| piaste wrote:
| > E.g. your linux distro might no longer package it and you
| might have to rely on packages maintained by redis which
| might not be as well integrated into your distro (although
| lots of users probably don't care about that)
|
| This might be me living in a bubble, but OS packages for this
| kind of server software really feel like a relic the past.
|
| Containers have been around for a decade and we now have
| tools like podman that run without privileges or daemons. I
| run my freakin' Raspberry Pi 4GB as a pure container host,
| just because it makes the system cleaner and more reliable at
| almost no cost.
|
| Now I'm sure some people still want to `apt install redis`,
| for example to squeeze every last ounce of performance out of
| hardware, and more power to them if that's what gives them
| the best results.
|
| But Debian maintainers have to do a lot of dull, unfun work
| to update, test, and bugfix native packages for Redis and
| Mongo and RabbitMQ and... is that really a good use of their
| precious, unpaid time? To make the UX and performance only
| slightly better than 'podman run redis'?
| vineyardmike wrote:
| It's not "open source" now.
|
| Your view on its impact is orthogonal to this reality. People's
| view on this reality is orthogonal to its impact
|
| Personally, I've grown tired of this debate. Redis is clearly
| commercial software. None of my "freedoms" rely on redis, the
| way they might on more core or primitive softwares like Linux,
| Bash, or a browser. The real (but non-exclusive) value of the
| invention lies in commercial applications. I'll bring out my
| "it's not OSS" pitchfork when VI or eMacs changes their
| licenses. I care deeply about open source software, but not
| _all_ source code matters.
|
| Contributing is a thankless task that benefits people's profit
| driven interests. It's understandable that contributors would
| like to try for some of that profit, and this doesn't seem to
| be too aggressive either. Yea, the relationship changed,
| because they were "giving it away" prior. But so what, life is
| full of changes. There is only a handful of organizations this
| will impact and they're all rich corporations that don't need
| my pity. The project is mature, so most remaining work is
| likely feature adds required by mega-scale and niche commercial
| uses cases, that's just not work people usually do for fun.
|
| Pardon my aggression - it's rhetorical- but redis doesn't need
| to exist in this world. It certainly doesn't need anyone's
| emotions.
| stavros wrote:
| Well, if you've grown tired of this debate, maybe I shouldn't
| reply, but maybe someone else wants to have it: Sure, it's
| not OSI-OSS, but what does that mean for the world, in
| practical terms?
|
| OSI-defined OSS means "comes with no restrictions, except
| maybe redistribution", whereas this license adds another
| restriction (you can't run the software as a service without
| offering the source, as I understand it). How does this
| restriction affect us?
|
| It surely can't be that OSS as defined by the OSI is the only
| good thing, and anything else is horrible, it has to be a
| continuum. Why is this license so bad, when it only affects
| AWS? How are my liberties being restricted?
|
| It doesn't really answer anything to say "it's not open
| source", because that just implies that we already agree on
| why that's bad.
| jeltz wrote:
| That Redis cannot be included in many Linux distributions
| anymore. Is that enough of a practical impact?
| zokier wrote:
| There is larger community impact of not being FOSS. Most
| immediate, distros will not package it anymore. Overall you
| will not be able to include Redis in FOSS projects in the
| same way anymore. In longer term this means that Redis will
| not enjoy similar integration with other projects; FOSS
| projects tend to prefer using/depending/integrating other
| FOSS projects, so Redis becoming non-FOSS means that it
| loses that preferred status. And so on.
| jen20 wrote:
| That may end up being a net win for all involved:
| distribution users will get an up to date package direct
| from the source instead of a 5 year old version (or
| whatever) patched to hell, and the project will stop
| getting reports about versions modified by packagers.
| vineyardmike wrote:
| Well I always welcome a healthy discussion so feel free to
| answer. I've really just grown tired of seeing outrage that
| software which was previously "OS as defined by the famous
| organizations" changes to protect their commercial
| interests.
|
| Like you said, there's a continuum, and I really don't
| think that "you can't sell this as a service" is a huge
| restriction on freedom. Especially when I can still use the
| software (even commercially) if I host it myself. Many of
| these services (Redis, Elastic Search, Mongo, etc) wouldn't
| really exist without commercial use cases, and I really
| care more about protecting individuals freedoms and the use
| case of a human using a machine in their own hands for
| their own use. The extent of my interest in OSS being
| good/bad (if you can make that claim at all) is in the
| impact to individuals at home.
|
| Also, the server side license just _feels_ like the modern
| viral license we should have. GPL ensures all code running
| together is forced open, and AGPL ensures clients are open,
| and this ensures that the server is open. Seems good to me
| the same way GPL or AGPL are good.
|
| I view it like government regulation. Bureaucracy is waste
| and I'm all for enriching society and creating new jobs and
| products with better commerce... but environmental
| protections and safety protections help society. If your
| business can't exist without endangering someone, I won't
| miss it. If your business exists solely to resell free
| software (explicitly designed for commercial use) that
| someone else made, and they don't want to give it to you
| for free anymore, I won't care it if you need to change up
| your business.
| stavros wrote:
| I think the disconnect here is that people think "it's
| either SSPL or GPL, and I want the GPL", when in reality
| it's probably "it's either SSPL or no more development",
| in which case I'd prefer the SSPL.
|
| If I don't mind antirez not working on Redis any more, I
| can always fork it and do my own development.
| inejge wrote:
| _Sure, it 's not OSI-OSS, but what does that mean for the
| world, in practical terms?_
|
| One practical consequence: Linux distributions will drop
| the new Redis, and ship its OSS fork or an alternative
| protocol-compatible cache. Or perhaps continue with the
| pre-license-change version for a while, which is a kind of
| fork. What was the relatively simple "apt install redis"
| will now be "apt install freeredis" or "apt install
| awesome-cache" or "apt install redis73". So you will have
| churn.
|
| I don't have an idea how many installations are via the
| official docker image; they won't change, but even there
| now you have a legal risk, however tiny: will Redis Inc.
| come after us for our usage? Legal departments are allergic
| to risk: witness their aversion to GPL variants, especially
| GPLv3 and AGPL. So perhaps there will be pressure to avoid
| Redis, again causing churn.
| ndiddy wrote:
| The restriction isn't that "you can't run the software as a
| service without offering the source." You're thinking of
| the AGPL, which is recognized as an open source license by
| the OSI. Redis's license has changed to the SSPL, which
| requires anyone who runs Redis as a service to release the
| source code to "all programs that you use to make the
| Program or modified version available as a service" under
| the SSPL. This makes it effectively impossible for a cloud
| provider to actually try to comply with the license, as it
| would require a massive engineering effort to write a new
| operating system, new device drivers, new programming
| language implementations, new web stack, etc all licensed
| under the SSPL.
| bawolff wrote:
| > There is only a handful of organizations this will impact
| and they're all rich corporations that don't need my pity.
| The project is mature, so most remaining work is likely
| feature adds required by mega-scale and niche commercial uses
| cases, that's just not work people usually do for fun.
|
| There is still a long tail on this. For example, wikipedia
| offers a cloud like platform thar people who contribute to
| wikipedia can sign up for free to, get some web space where
| they can make small unofficial tools, provided that the tool
| is somehow related to wikipedia. This includes redis hosting
| among other things (https://wikitech.wikimedia.org/wiki/Help:
| Toolforge/Redis_for... ). The license change would probably
| effect that use case ( the RSAL would prohibit that. The
| situation with the SSPL is less clear (IANAL))
| sakjur wrote:
| It opens you up to a larger litigation surface. Previously, you
| didn't risk having to explain to a court that you're really not
| offering Redis as a service even though your service is using
| Redis.
|
| Copyleft licenses are limited to the software itself, but SSPL
| expands this to "including, without limitation, management
| software, user interfaces, application program interfaces,
| automation software, monitoring software, backup software,
| storage software and hosting software". If there's even the
| tiniest risk of having to comply with that, I'd stay clear of
| anything SSPL licensed.
| stavros wrote:
| That makes sense, thank you.
| keyle wrote:
| Doesn't that change need to be tied to a release number?
|
| "Starting on March 20th, 2024" doesn't seem right to me.
| wodenokoto wrote:
| That sentence immediately continues with
|
| "... Redis follows a dual-licensing model with all Redis
| project code contributions under version 7.4 and subsequent
| releases governed by the Redis Software Grant and Contributor
| License Agreement."
|
| So it is tied to version 7.4
| sakjur wrote:
| (IANAL) Every commit is a derivative, I don't think the
| numbered releases have any impact on that. Say you fork Redis
| now, from the commit that changed the license, that's a
| different "version" of the software compared to the commit just
| before that is practically the same but using the BSD-3
| license.
| randomdev3 wrote:
| I didn't know Redis Inc. has over 500 employees. It's hard to
| support that with a basically free product and some own cloud
| services..
| epolanski wrote:
| And you could be safe assuming at least 10% is sales.
| erlend_sh wrote:
| The 'Redis Source Available License 2.0 (RSALv2) Agreement' is a
| relatively succinct and human-readable license. Still, I really
| wish these non-compete licenses would come with a few examples of
| use cases that are definitively non-infringing, to remedy any
| uncertainty.
|
| Between this non-compete clause of their license:
|
| > 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.
|
| ..and this clarification in their FAQ:
|
| > A "competitive offering" is a product that is sold to third
| parties, including through paid support arrangements, that is
| derived from the Redis' code-base and significantly overlaps the
| capabilities of a Redis commercial product. For example, this
| definition would include hosting or embedding Redis as part of a
| solution that is sold competitively against our commercial
| versions of Redis (either Redis Enterprise Software or Redis
| Cloud).
|
| It's pretty clear that any SaaS product simply using Redis as a
| dependency for a completely different product (e.g. Discourse) is
| in the clear. But it would be nice if they could spell that out
| as an unaffected use case.
| slhck wrote:
| I agree it would be good to clarify this. I have a product that
| does some background job processing using Sidekiq and Redis,
| and it seems that this would not constitute "making the
| software available", in particular where it says:
|
| Making the functionality of the Software or Modified version
| available to third parties includes (...) offering a product or
| service, the value of which entirely or primarily derives from
| the value of the Software or Modified version (...).
|
| Since the value is not _primarily_ derived from using Redis, I
| guess it's fine. I am sure the majority of projects using Redis
| in some way do not derive their main value from Redis.
| dark-star wrote:
| Classical "bait-and-switch". Bait users and developers with a
| fully-open and freely-licensed project, wait for it to gain
| enough market share, then switch the license to a more
| restrictive one...
|
| In a few days, a clone called "Libredis" or "Freedis" will
| probably appear that the community and developers will move to.
|
| So yeah, it might be annnoying buit in the long term it won't
| matter much anymore (same as the company)
| Dylan16807 wrote:
| Is it really bait and switch if almost zero users are affected
| by the change? (except philosophically)
| RyEgswuCsn wrote:
| It's salami bait and switch.
| repeekad wrote:
| It's bait and switch to community developers who contributed
| free labor to a for profit company for what is now either a
| fork or a more restrictive license
| nicolas_t wrote:
| What percentage of commits were made by community
| developers?
| otterz wrote:
| Why should that matter? I'm sure the percentage would be
| way smaller if this was the license used initially.
| wasmitnetzen wrote:
| All clients will still be Open Source and a lot were
| initially written by the community as far as I'm aware,
| so they're actually still asking for free labor there.
| rsstack wrote:
| The company Redis only adopted the Redis project (and
| changed its name) a few years ago. Redis started as a
| community project and was run that way for almost a
| decade.
| bbotond wrote:
| About 75% afaik.
| kjksf wrote:
| The version they contributed to is still available under
| the same permissive license that was in effect when they
| were contributing the code.
|
| The license change only affects the code written in the
| future and now people can change their mind about
| contributing.
|
| That seems fair to me.
|
| Maybe you think that morally the license should never
| change but there is no clause in the license to prevent
| changing the license, so that would not be a reasonable
| expectation.
| cqqxo4zV46cp wrote:
| This shows a fundamental misunderstanding of how open
| source licenses work. I am completely sick of this take.
| It's intellectually dishonest, or extremely ignorant.
| repeekad wrote:
| Never attribute to malice that which can be explained by
| stupidity
|
| Reading the other comments the switch does make more
| sense, if you want to freeload off of the work redis has
| done for the project then you'll have to join whatever
| community remains on the forked version, and anyone who
| cares about this kind of stuff should probably understand
| what's permissible in the previous license, which clearly
| includes it being switched out like this
| happymellon wrote:
| They contributed free labour under a licence that says that
| anyone can do anything they want, including offering it
| under a different licence.
| gramakri2 wrote:
| Why do you think almost zero users are affected by this
| change? If a business was built on hosting redis or providing
| managed redis, that company is now inviable, no?
|
| note: I am not disagreeing with the license change, just
| asking why you think nobody is affected.
| vineyardmike wrote:
| If a company is built on hosting redis - and is now
| unviable, they should be pretty incentivized to fork the
| previous version and maintain it themselves. Isn't that the
| power of open source?
|
| I doubt there were many (if any) non-AWS businesses that
| were affected. To earn a profit you need to continue to
| work, I don't feel bad when a corporation is negatively
| affected after their leeching or rent seeking is disturbed.
| Even if it was previously acceptable behavior.
| cebert wrote:
| > " I doubt there were many (if any) non-AWS businesses
| that were affected."
|
| Momento is likely impacted.
| gramakri2 wrote:
| But that is not what I am asking though. The OP is saying
| almost 0 users are affected and this is not true.
| tejasbaldev wrote:
| That's exactly the point. Companies providing managed
| services on top of popular opensource projects are not
| contributing to the respective OSS project at the scale at
| which they've been benefitting commercially from these
| projects.
| jen20 wrote:
| Aiven is a good example - I don't know if they contribute
| to Redis, but they appear to offer a managed service
| based upon it.
| gramakri2 wrote:
| Not sure what exactly the point is. The OP is saying
| almost 0 users are affected and this is not true. I was
| only saying that the license change affects quite some
| people. Whether rightly or wrongly is not mine to debate
| (I have nothing to do with redis!).
| arp242 wrote:
| "Almost zero", not "exactly zero".
| fweimer wrote:
| Anyone installing a distribution package will be impacted
| eventually.
|
| https://qa.debian.org/popcon.php?package=redis
| ctrw wrote:
| Will no one think of Amazon's profit margins?
|
| We need new licenses that let developers get more of the pie
| because no one is benefiting from the GPL in the age of cloud
| computing. Who cares that Linux is open source when I'm locked
| in aws and can never leave? What does it matter to users when
| their data is stolen to train Ai models and they don't even
| know what's in it?
| rglullis wrote:
| > We need new licenses that let developers get more of the
| pie because no one is benefiting from the GPL in the age of
| cloud computing.
|
| Try the AGPL.
| ctrw wrote:
| A license for the internet of the 90s, not the one we have
| today.
| bberenberg wrote:
| Can you elaborate on this? I have seen a fair amount of
| criticism of AGPL on here recently and am trying to
| understand the perspective.
| madeofpalk wrote:
| What's wrong with AGPL? Why is it not suitable for the
| "internet of today"?
| throwaway48476 wrote:
| It's not viral enough. It's easy for AWS to host a
| version of an AGPL project and just point to the source
| code. Cloud hosted instances are the primary business
| models for a lot of projects. The solution is to add a
| requirement that any platform the software is hosted on
| also has to be open source.
| rglullis wrote:
| > Cloud hosted instances are the primary business models
| for a lot of projects.
|
| No one is entitled to their business models, no matter
| how noble their goals.
|
| It's quite simple: if you believe in the ethos of Free
| Software, you need to be prepared to the possibility of
| other people taking your work, doing modifications and
| even profiting from it. _That is the whole point._
|
| If you don't want "evil corporations" from taking your
| code, then keep it closed and _say it so_. But don 't be
| dishonest with others when you say that you "support open
| source" while not ready to walk the walk.
| jen20 wrote:
| SSPL achieves your goal far better than AGPL, as already
| enumerated in this thread.
| thejohnconway wrote:
| People are struggling with what I think of as the pyrrhic
| victory of open source software. Vast swathes of
| computing is done with OSS, yet there is very little
| software freedom for actual people, because it's all
| running in megacorps data centres with all the data
| locked away.
|
| Essentially, the intention of copyleft to increase
| software freedom, which is the overall mission, has
| foundered. It is didn't work and need revising.
|
| Smaller companies are an ally of convenience here.
| rglullis wrote:
| No, the problem is that people conflating "free as in
| speech" with "free as in beer". Data is locked in
| megacorps because people are giving away their freedoms
| in exchange of convenience.
|
| > the overall mission, has foundered.
|
| Absolutely not. I've never had so much freedom on how to
| do computing.
| thejohnconway wrote:
| I don't think the intention of OSS was to make computing
| more free for a tiny elite who are will to live with
| quite a lot of inconvenience. Maybe I'm wrong. I
| certainly don't think the average computer user is more
| free in their software use than they were, say, 10 years
| ago. Or 20.
| rglullis wrote:
| 1) The average user has a lot more choices of free
| systems to use. That they still prefer to lock themselves
| to a closed platform is not a failure of FOSS.
|
| 2) in the worst case analysis, FOSS trickle downs to
| people. Eg: WhatsApp could only have started if we had
| FOSS. It may have been colored by Facebook, but at the
| end of the day it was thanks to it that the "non-elite"
| managed to disrupt the telcos and offer messaging for
| free.
| thejohnconway wrote:
| It absolutely is a failure of FOSS. It was supposed to be
| viral, leading to greater software freedom for all. The
| strategy has been countered and subverted by running FOSS
| on servers people don't control.
|
| Half the world's communication being under the control of
| one company with a dictator is hardly a success.
| rglullis wrote:
| Are we arguing over "freedom from" and "freedom to"?
|
| I don't like that so many people preferred to go for a
| closed solution and I certainly don't like virtual
| monopolies, but people are there out of their own
| volition.
|
| 30 years ago, there was no real alternative for Windows
| on the desktop. All productivity tools were closed.
| Today, people buy iPhones and sign up to Instagram/TikTok
| because _they want to_.
|
| What would you propose, to have Stallman pointing a gun
| to everyone who didn't attend a install fest?
| Dylan16807 wrote:
| > 30 years ago
|
| But they were comparing to "10 years ago. Or 20."
|
| > What would you propose, to have Stallman pointing a gun
| to everyone who didn't attend a install fest?
|
| If I can propose wild things, then I'll propose that
| something forces big hosting companies to share their
| code.
|
| And data freedom is an important issue that has a huge
| overlap with software freedom. I like the EU's movement
| toward forcing export and interoperability for big
| entities.
| rglullis wrote:
| > But they were comparing to "10 years ago. Or 20."
|
| Linux only became a viable desktop around 2010.
|
| Blender was open sourced in the early 2000.
|
| StarOffice was a viable alternative to MS Office 2003.
| Dylan16807 wrote:
| Yes...?
|
| The more things you list that are before the year(s) they
| used as reference points, the more you support their
| argument that software freedom peaked a while ago and has
| been going downhill in major ways in more recent years.
| rglullis wrote:
| My point is that I can continue with the timeline, and it
| will trend towards _more_ freedom, not less:
|
| - Google's original Android was more open than any of the
| alternatives. And even if Google went on the direction of
| closing Android and putting functionality around its Play
| Services, there are a good number of alternatives that
| build on Android and make it _completely_ free. The
| number of devices that can run LineageOS /Murena/Linux is
| going _up_ , not down.
|
| - All social media was closed, and now we are seeing an
| explosion of open source projects. The number of people
| using it is going _up_ , not down.
|
| - Self-hosting software is easier than ever.
|
| I fail to see any time interval where the availability of
| free software has been reduced. All it takes is a
| motivated individual.
| Dylan16807 wrote:
| > the problem is that people conflating "free as in
| speech" with "free as in beer"
|
| Huh? Where?
|
| I don't see how that confusion applies to the tradeoffs
| discussed here.
| rglullis wrote:
| Basically everyone who complains about proprietary/closed
| software and platforms and claims to "support" FOSS but
| never put their money where their mouths are.
|
| Every company that pays through the nose for their cloud
| hosting, but does not allocate anything in their budget
| to support the downstream projects.
|
| Every owner of a pricey Apple device who claims "they
| need something that just works" but never spared a few
| dollars per month to contribute to the development of
| free alternatives.
|
| If a fraction of these people realized that quality free
| software takes money to be developed, and were willing to
| invest in it, the FOSS funding issue would be solved. The
| problem is, people are not willing to pay for R&D, they
| just want to pay for the finished product.
| Dylan16807 wrote:
| People not wanting to pay for things is a big problem in
| that way, yes.
|
| But the problem is not because they're conflating it with
| "free as in speech". They're ignoring that aspect
| entirely.
| madeofpalk wrote:
| What's your outcome? Are you actually asking for a "No
| AWS" license?
|
| AGPL is fine - it ensures that open source projects
| remain open source. If a vendor hosts an AGPL project _as
| is_ (unlikely imho) and is able to point to the existing
| repo for source, then that 's great. If they make changes
| to the code, they must also make that source available
| through a compatible license.
| ctrw wrote:
| I can provide agpl software for a printer driver which
| none the less doesn't let you load the source code for
| the printer driver.
|
| If the original case for the GLP is still not covered by
| the AGPL in $current_year open source licenses have
| failed.
| piaste wrote:
| > The solution is to add a requirement that any platform
| the software is hosted on also has to be open source.
|
| Even that is a somewhat temporary hack. The SSPL spreads
| to:
|
| > "management software, user interfaces, application
| program interfaces, automation software, monitoring
| software, backup software, storage software and hosting
| software, all such that a user could run an instance of
| the service using the Service Source Code you make
| available"
|
| and sure, AWS and Azure definitely don't want to open
| source all of that stuff now, or for the next decade or
| two.
|
| But that's not their competitive advantage; that's their
| datacentres and their sheer gigantic size and deep
| pockets, making them a "safer" partner for enterprises.
| National governments won't run a critical service on
| Redis Cloud when Azure Redis is available, even if the
| software stacks were 100% identical.
|
| It's quite possible to imagine a cloud provider in 2040
| that _does_ run a fully OSS stack and is able to sell
| SSPL software on a massive scale without paying a cent to
| the original developers. Doesn 't even have to be a new
| actor, Amazon could spin-off a separate experimental
| organization for that purpose.
|
| If that were to happen, could another license solve the
| problem?
| anonymous_i wrote:
| Stupid ask:
|
| Can't developers sue this company for false advertising ?
|
| This started off as one thing and ended up being something
| else. They probably at any point did not hint about
| changing license in the future, just guessing.
|
| For any open projects , couldn't dev. request for keeping
| the license as is or Free(or whatever relevant) before
| letting their code merged.
|
| This may sound illogical to someone who is a domain expert,
| but this is just a dumb question from someone who has
| almost 0 clue on this topic.
| mpweiher wrote:
| > Can't developers sue this company for false advertising
| ?
|
| No.
|
| Questions for you:
|
| 1. What was advertised?
|
| 2. By who?
|
| 3. Where?
| sebstefan wrote:
| Redis picked SSPL instead and cited those reasons for why
|
| "It is based on the AGPL, with a modified Section 13 that
| requires that those making SSPL-licensed software available
| to third-parties (modified or not) as part of a "service"
| must release the source code for the entirety of the
| service, including without limitation all "management
| software, user interfaces, application program interfaces,
| automation software, monitoring software, backup software,
| storage software and hosting software, all such that a user
| could run an instance of the service using the Service
| Source Code you make available", under the SSPL. MongoDB is
| the publisher of this license. They have a FAQ about the
| license https://www.mongodb.com/legal/licensing/server-
| side-public-l..."
| arthur_sav wrote:
| > community and developers will move to.
|
| I have never seen a fork last long enough.
| jaylittle wrote:
| MariaDB called and said, "I'm still here" ;)
| ktosobcy wrote:
| Is it really used/ popular?
| prox wrote:
| Yes
| nasretdinov wrote:
| At some point I believe Google had the largest MySQL
| installation in the world and they were using MariaDB.
| georgyo wrote:
| very yes
| graemep wrote:
| Yes, it replaced MySQL in Debian, and many other distros.
| The only shared web hosting I know about uses it on
| FreeBSD, etc. It seems to be more widely used then MySQL
| at this point.
| jeltz wrote:
| Yes, when most people say MySQL they actually mean
| MariaDB.
| nolok wrote:
| Unless you actively want the support contract with
| Oracle, there is no reason not to use MariaDB instead.
|
| Debian changed it to the default quite a while ago, and
| it's full support for mysql compatibility means you
| sometime don't even notice it (eg "mysql" is starting
| mariadb client).
| bawolff wrote:
| I mean, its powering Wikipedia right now and that's the
| seventh most popular website in the world.
| tick_tock_tick wrote:
| It's so popular I've never seen anyone actually use the
| original.
| jeltz wrote:
| LibreOffice? MariaDB? X.Org?
| elric wrote:
| FreeBSD? NetBSD? OpenBSD? Half of all Linux distros?
|
| Seriously, the number of succesful forks is huge.
| eqvinox wrote:
| FRRouting forked from Quagga. Quagga is dead now, FRRouting
| is on overdrive.
| sebstefan wrote:
| Like which one? Like the other commenters under you, I can
| only think of forks that lasted long enough
|
| Probably some survivor bias
| jeltz wrote:
| Yeah, survivor bias. Most forks die, but there are plenty
| of successful ones.
| raverbashing wrote:
| How is the Terraform fork going, by the way? (honest question)
| hacktivity wrote:
| First stable GA release in Jan. They're talking up the
| pending 1.7 release...
| https://www.thestack.technology/opentofu-1-7-business-value/
| cube2222 wrote:
| Hey, tech lead of OpenTofu here.
|
| It's going excellent! I'm surprised by how well adoption is
| going.
|
| Just the day before yesterday we had OpenTofu Day at KubeCon,
| and instead of the expected ~30 people we had 150-200
| attendees and a packed room!
|
| The next major release, 1.7, is coming out soon too.
| Alifatisk wrote:
| I don't think this is about bait-and-switch, I believe (like
| some other comments mentioned) they want a bigger part of the
| pie. It's same story as what Elasticsearch went through, this
| an understandable move.
| Aachen wrote:
| Do you really think they planned this from the start, intending
| to change the license as soon as enough people use it? To me,
| that's reading malice into a situation that could equally be
| explained by changing circumstances over time, which does not
| meet the definition of bait and switch
| tejasbaldev wrote:
| Could you expand on ''bait & switch''
|
| What exactly is the material impact on a developer with this
| licensing change? There is a tendency these days to
| sensationalise things without getting to the bottom of it or
| even reading the whole article.
|
| What did the OSS Redis project promise a developer that it is
| not going to deliver in the new licensing model?
| anymouse123456 wrote:
| For me, using OSS means that if I bump into a problem, I can
| fix it and use, and share the fix. Yes, I've created OSS
| projects and contributed to others.
|
| It also means that if the people providing the software
| decide to change the deal to something that is too onerous
| for me to accept, I have options that don't disrupt the
| continuity of my business.
|
| If I no longer have those rights, I'm no longer willing to
| rely on this software.
|
| Unfortunately, it's far from trivial to rip Redis out of a
| running application environment and they know that.
|
| This kind of change feels like a bait & switch to so many
| people, because it is a bait and switch.
|
| Now that it has been integrated, and could cost hundreds of
| thousands or millions of dollars in labor to rip out, they
| change the deal.
|
| We've been reassured for many years that this is OSS and it
| will always be OSS and many people relied on that assurance
| to place a hard and expensive dependency on this software.
|
| That is a betrayal of trust and it's hard for me to
| understand how people aren't seeing it that way.
| acdha wrote:
| How do you think your freedom to "fix it and use, and share
| the fix" is changing? Unless you're running a Redis hosting
| service isn't it business as usual?
|
| I don't love the direction that the open source world has
| been moving in but in terms of practical impact on my work
| this seems to be minimal. I think the easy money during the
| VC bubble lead a lot of us to get used to high-quality
| software not having a plausible business model and we're
| going to see a lot more of this, which makes me wonder if
| OSI could come up with some kind of hybrid license allowing
| maintainers to get paid but not giving up too much freedom.
| Otherwise it feels like we might see a move back towards
| closed-source development.
| weinzierl wrote:
| This is one way to see it. The other side of the coin is that
| this move is totally in their rights, morally and legally.
|
| It is our obligation as developers to communicate to companies
| if we want these license changes to happen or not. If you don't
| like it, don't contribute and invest your time into projects
| that are not licensed in way that matches your needs and wants.
| anonzzzies wrote:
| > This is one way to see it. The other side of the coin is
| that this move is totally in their rights, morally and
| legally.
|
| Morally I would say it depends on contributors. If there
| haven't been any then sure, but if I contributed a feck-load
| of code to some project and they slap on a commercial
| license, I guess I feel somewhat shafted.
| weinzierl wrote:
| _" license, I guess I feel somewhat shafted."_
|
| You shouldn't. If you contribute to a project under a
| permissive license that is what you sign up for.
|
| I contributed to projects under permissive licenses myself,
| there is nothing wrong with it. Being indignant about
| companies exercising the rights you explicitly granted them
| is unwarranted though.
| anonzzzies wrote:
| You can always fork in that case, I guess.
| weinzierl wrote:
| You can, and that is ok. It would not help you if you
| feel shafted, because then the next company comes around
| and takes your contributions, uses them as intended
| without giving back and you'd still feel the same.
|
| I think you should not feel shafted, but if you do there
| is a simple and obvious solution.
| lol768 wrote:
| > It is our obligation as developers to communicate to
| companies if we want these license changes to happen or not.
| If you don't like it, don't contribute and invest your time
| into projects that are licensed in way that matches your
| needs and wants.
|
| The best thing you can do is to fork the project at the
| commit prior to the license change, and maintain it from that
| point onwards (and/or contribute to other forks with the same
| goal).
| happymellon wrote:
| > The best thing you can do is to fork the project at the
| commit prior to the license change, and maintain it from
| that point onwards
|
| And use an appropriate license. Don't use BSD if you don't
| want people taking your stuff and closing it up.
| jsiepkes wrote:
| > The other side of the coin is that this move is totally in
| their rights, morally and legally.
|
| Legally, sure. That's pretty binary.
|
| But if you claim they have the moral right to do so you need
| to elaborate on that. Since they had a "social contract" with
| the community (people who submitted PR's, advocated for
| Redis, etc.) which a single side has now altered. I don't see
| how one can do that an claim to be in their moral rights to
| do so.
|
| We've altered the deal, pray we don't alter it any further...
| exe34 wrote:
| They haven't taken anything away from the community though.
| You can still fork it and maintain it going forward. It's
| the same as if the entire redis team died in a bus crash.
|
| What they did do is decide that in the future, their work
| won't be as easily taken advantage of.
| weinzierl wrote:
| If you think that your "social contract" has been violated
| that that is because you are mistaken about the contract
| you entered into.
|
| This would only be immoral if you were misled or forced,
| and I'd argue that neither is the case here.
|
| All the contributors gave their explicit permission to use
| their contribution in the way Redis does.
|
| All contributors had plenty of freedom to spend their
| energy in projects under a license that specifically
| prevents what happened with Redis. It is not that they
| wouldn't have other options.
| happymellon wrote:
| > which a single side has now altered.
|
| No they haven't. "The community" submitted under a BSD
| licence, they literally gave _anyone_ permission to take
| their code and relicence it under an alternative.
|
| It's not like the BSD version of their code has
| disappeared. You can still use older versions of Redis that
| have their changes under BSD.
|
| It sounds like submitters should have gone with GPL or AGPL
| if they wanted it to remain open source, available with the
| original licence for commercial use, etc.
| ExoticPearTree wrote:
| Actually, if i read the below correct, on the server-side side
| license part, they want any company to publish the source code
| of any Redis-as-a-Service product is being developed:
|
| If you make the functionality of the Program or a modified
| version available to third parties as a service, you must make
| the Service Source Code available via network download to
| everyone at no charge, under the terms of this License. Making
| the functionality of the Program or modified version available
| to third parties as a service includes, without limitation,
| enabling third parties to interact with the functionality of
| the Program or modified version remotely through a computer
| network, offering a service the value of which entirely or
| primarily derives from the value of the Program or modified
| version, or offering a service that accomplishes for users the
| primary purpose of the Program or modified version.
|
| Which sounds pretty good and is the complete opposite of what
| Mongo or Elastic are doing.
| LikelyABurner wrote:
| Yeah, I don't like that we're at the point that we need
| licenses like this, but in a world where AWS has decided to
| "disrupt" the methods for open source monetization that the
| open source community has generally agreed upon as being in
| the spirit of open source, I don't see any other option.
| dragonwriter wrote:
| The methods in question are not the ones that the open
| source community has agreed upon, they are ones that the
| FOSS community had identified as being non-viable, with
| detailed reasoning, before the OSI was even founded. The
| fact that a handful of founders and VCs decided to ignore
| this established wisdom does not constitute an general
| agreement by the "open source community".
|
| The consensus that simply selling FOSS software (and
| renting access to it is not substantially different in this
| regard) is not a viable method of monetizing FOSS as an
| independent business centered around a particular piece of
| FOSS because large established firms with established
| hardware, professional services, and other associated lines
| of business and the ability to integrate it with their
| other offerings would eat your lunch was established by, at
| the latest, the mid-1990s.
| c-flow wrote:
| Elastic also has a dual license.
| happymellon wrote:
| Why not just use the AGPL?
| catwell wrote:
| Talking about bait and switch for Redis makes no sense.
|
| Redis is a 15 years old project started in 2009 by Salvatore
| 'Antirez' Sanfilippo. He worked on his startup, then at VMWare,
| them at Pivotal, and only joined Redis Labs (created in 2011)
| in 2015.
|
| In 2018 Redis Labs changed the license of their modules and
| Antirez published http://antirez.com/news/120 In 2020 he quit.
|
| Anyway I agree with the conclusion: Redis will be forked, the
| fork will win and Redis Labs will become irrelevant.
| tudorg wrote:
| I'm curious about something: I suppose Salvatore still owns
| the copyright for most of the code? The old license does
| include his copyright, up to 2020:
| https://github.com/redis/redis/blob/7.2/COPYING So I think
| this change couldn't have been done without his explicit
| consent? Or did he transferred his rights to RedisLabs or a
| foundation?
| weinzierl wrote:
| What your link points to is the BSD license, so yes, he
| owns the copyright but also gave everyone permission to use
| and modify the code as they see fit.
|
| There is nothing that prevents anyone to use this code in
| combination with proprietary code and sell the resulting
| project for money. If he didn't want that he would have
| chosen a different license.
| tudorg wrote:
| Ah, makes sense, thanks! And they do own the trademark,
| it seems.
| jeffparsons wrote:
| Are you talking about the developers who willingly contributed
| code under the BSD licence? The same BSD licence that says that
| it's completely fine for the company to do this?
|
| It's such a strange pattern that plays out again and again:
| developers insist that a permissive license is the way to go,
| until somebody (or company) they don't like exercises their
| rights.
|
| Usually what said developers actually wanted was the GPL,
| because they realise in retrospect that they didn't want the
| company to be allowed to do this. But they didn't like it
| because it restricts recipients rights. So they want people to
| have those rights as long as they never actually exercise them?
| It's all very confusing.
|
| I say this having contributed to and released my own projects
| under both permissive and copyleft licenses -- based on what
| I'm actually willing for people to be able to do with the code.
| zelphirkalt wrote:
| To a large part it is probably simply uninformed developers
| choosing permissive licenses, because some of their favorite
| projects do so as well and that is what they know as "open
| source". The thought seems to be along the lines of:
|
| "I am going to make it open source! What license was that
| again? Ah MIT license! OK, done!"
|
| Only later, when a project has gained traction they might or
| might not realize that MIT license allows people to do things
| they would not like. But by then they need to ask all the
| contributors for a license change and it typically doesn't
| happen.
|
| Often the people also think they must not upset companies, if
| companies uses their software. Sometimes there is also
| financial motivation behind that. Big players invest into
| that project directly or conferences or other things, giving
| the people involved in the project some fame. See for example
| project Jupyter. One look at the $ponsors and you know why
| they will never change to a copyleft license.
|
| That is alright, but people should not be surprised, when the
| rug is pulled away under their feet and big tech creates some
| closed source alternative or derived work under a different
| license, that integrates with their other stuff and that the
| original authors do not see a penny of, even if millions of
| people use it.
|
| When I decide on software to use for myself, and I have a
| good choice between something copyleft and something MIT or
| similarly licensed, I usually go for the copyleft one,
| because I have no interest in the corporate involvement.
| barkingcat wrote:
| Do people not read licenses that they use? MIT means anyone
| can use it for anything. The text is very short, and very
| clear.
|
| why are people surprised when other people start using the
| software/close sourcing/packaging it and selling it?
| lenocinor wrote:
| I think for most devs, software licenses are not a core
| competency. Most devs interact with licensing only
| occasionally, if that, and they may not have a good grasp
| of the licenses they work under (or if they do, they may
| forget parts of their understanding later).
| xinayder wrote:
| This is written in their blog post:
|
| > Under the new license, cloud service providers hosting Redis
| offerings will no longer be permitted to use the source code of
| Redis free of charge.
|
| So, this is just a money grab scheme because Redis finds it an
| absurd that cloud providers are offering Redis hosting, in
| their minds Redis Company should be the only one offering Redis
| hosting.
|
| Maybe I'm wrong, but I believe this is a shotgun shot to their
| foot and this will result in Redis dying or even drastically
| reducing its market-share.
| renegat0x0 wrote:
| Redis.io no longer mentions open source.
|
| They have still not changed meta description on their page. It
| still says it is open source ^^
|
| view-source:https://redis.io/
| jeswin wrote:
| More Open Source projects should adopt SSPL, or experiment with
| LLama 2 style limitations on the size of companies which may use
| the work for free (for example, Open Source but not if you're a
| multi-billion cloud megacorp). When individual developers
| contribute back, they weren't doing it to enable AWS to freeload.
|
| AWS of course is the single biggest reason why projects are
| flocking to more restrictive licenses. The right thing to do for
| AWS would have been to respect the work of the original authors
| (/company) and throw their weight behind an offering supported by
| the original developers. Instead, AWS builds a competing product
| when they see an OSS product succeeding. Third party vendors
| stand no chance after that due to the tighter integration and
| marketing muscle.
|
| Not to mention, Amazon and AWS give so little back to Open Source
| despite being a big (the biggest?) beneficiary. Google, Microsoft
| and even Oracle do more for Open Source than Amazon.
| jeltz wrote:
| I am fine with SSPL and AGPL as long as there is no CLA which
| makes me sign me rights over to someone else. I have never
| contributed to a project with a CLA and unless an employer pays
| me for it I do not think I ever will.
| elric wrote:
| I certainly won't sign CLAs to entities like IBM
| (Eclipse/RHEL) or Oracle. But I did willingly sign a CLA for
| the Apache Software Foundation. I didn't enjoy doing it, but
| at least they're a force for good.
| aragilar wrote:
| But Apache I believe specifically is bound to offer code
| under the Apache licence?
| ShaneCurcuru wrote:
| If you simply believe "CLAs are bad", you're missing the
| point (unless you refuse all legal documents on principle,
| or something).
|
| The question is: WHO are you signing the CLA over to?
|
| If it's a for-profit company, well, then do you trust that
| company to follow through?
|
| If it's a non-profit, then look to see (in the US) if
| they're a 501(c)(3) public charity, which have legal
| restrictions on their governance, which typically require
| serving some larger public good. Also look at their history
| of past governance. I certainly hope (as an ASF peep) that
| we've shown who we are to be who we plan to be in the
| future; namely producing software for the public good.
|
| Key reasons the ASF uses a CLA are protecting the org from
| future IP issues, and partly simply to be able to fix some
| future typo or legal issue in our license if one ever comes
| up. But the ASF will _always_ provide all of it 's released
| software under a similar style permissive license to
| Apache-2.0, as long as the organization is around.
|
| If they're a 501(c)(6), then they're a business league, and
| might act more like a for-profit corporation, so...
| elric wrote:
| It's important to remember that FOSS contributions are on
| a voluntary basis. When I have to sign paperwork, things
| start to feel like unpaid work.
|
| Signing legal documents requires disclosure of personal
| information. Most CLAs require full legal names and often
| the names of employers. While Elric is my legal name, I
| prefer not to disclose my last name for a variety of
| reasons. Being able to commit to FOSS on a pseudonymous
| basis is impossible when CLAs are involved, which I think
| is a real shame.
|
| I understand that orgs want to protect themselves, but
| CLAs only protect orgs, and can potentially harm
| contributors. Now, I happen to trust the ASF, and I hope
| my personal information is safe with them.
| bluGill wrote:
| > the ASF will always provide all of it's released
| software under a similar style permissive license to
| Apache-2.0, as long as the organization is around.
|
| What makes you think that? What stops a few "evil" people
| from getting on the board and changing the mission in
| some way and then changing the license so that it is no
| longer permissive?
|
| I've never been clear on what stops the above attack.
| Many people have setup foundations on their death that
| are now promoting things the person was clearly against
| in their life. Martin Luther King Jr's "I have a dream"
| speech is now property of his heirs who milk that
| copyright for all the dollars they can get - I believe
| this is not what he would have wanted. There are plenty
| of other examples.
| ShaneCurcuru wrote:
| Personally I know it since I've been volunteering there
| since 1999 and know how elections work and know most of
| the membership. But that probably doesn't help much if
| you don't know me.
|
| Practically, I know it because the ASF is a Membership
| organization, meaning there are hundreds of individual
| Members who have been elected by their peers inside the
| ASF. The Membership is the group who elects the board.
| The ASF has only individuals as Members (never
| corporations), and quite a lot of folks have made their
| careers about their ASF project work, while hopping
| between multiple jobs at various vendors.
|
| So to mount an attack like that, you'd need to "evil-ise"
| a over a hundred Members to get them to vote for your
| hand-picked candidates who would be shunned by basically
| everyone else involved in the ASF.
|
| https://apache.org/foundation/governance/members.html
|
| Vendor neutrality and our permissive license are baked
| very, very deeply into everything the ASF does.
|
| A fair number of 501(c)(3) foundations are similarly
| membership corporations, where the board is elected from
| the set of people who've been volunteering there for
| years, so they are unlikely to change direction like
| that. Some (c)(3)s are not, but still have a good track
| history. (c)(6) organizations are a mixed bag, since some
| explicitly allow sponsors to pay for board seats - a very
| different world.
| jimjag wrote:
| Not all CLAs are the same... for example, the CLA from the
| ASF is NOT a copyright assignment. Other CLAs _are_.
| jeltz wrote:
| Ok, that is a very valid point. It is CLAs with copy right
| assignments I am opposed to.
| elric wrote:
| Some time ago I tried to argue for a FOSS license that would
| disallow code from being used by AI. I got a lot of negative
| feedback saying that this wouldn't be FOSS because it imposes
| restrictions etc. The same is true for the SSPL. But for long
| term FOSS viability, I think we may need to impose some
| restrictions to protect ourselves from big bad megacorps who
| effectively exploit FOSS developers.
| andybak wrote:
| I am still not entirely convinced that "disallowing code from
| being used by AI" is going to hurt megacorps in the long run
| - or the individual.
|
| I guess plenty of people have already made their own call on
| this matter but I'm still genuinely undecided. As much as the
| megacorps are rushing to rule the AI roost - it's possible it
| will turn out to be a universal solvent to some degree.
|
| But I'm also pretty lukewarm about AGPL and SSPL. I feel
| there's a huge amount of fragmentation in open source land
| and I'm often unable to use code in situations where I feel
| the original creator would probably have been ok with it.
| elric wrote:
| The phrasing "used by AI" was a bit simplistic. I agree
| that this is not a black/white situation. Maybe everyone
| will benefit eventually. But it would have been nice to
| have the option.
| satvikpendem wrote:
| What does code being used by AI have to do with "big bad
| megacorps who effectively exploit FOSS developers?" I don't
| see any connection there, while I do see it for something
| like SSPL.
| marklar423 wrote:
| It's a semantic thing and I agree with the feedback -
| specifically with the "F" in FOSS. That sort of license would
| be Open Source but not completely Free (as in freedom, not
| beer).
| dig1 wrote:
| > AWS of course is the single biggest reason why projects are
| flocking to more restrictive licenses
|
| Don't forget that AWS is one of the biggest reasons so many OSS
| projects became popular. Redis, Mongo, ES, HashiCorp stuff, a
| complete big data ecosystem, got wider recognition through
| AWS's offering. Many people have yet to learn about dozens of
| obscure databases (that have been in development for years)
| simply because AWS or other big cloud providers have not pushed
| them.
|
| Also, many projects receive a lot of contributions (bug
| reports, PRs, patches) due to liberal licenses increasing their
| use and popularity. I'm not particularly eager to contribute to
| anything with SSPL/BSL/etc-like licenses simply because I don't
| want to waste my time on something I can't use liberally in the
| future.
| codedokode wrote:
| Redis was popular enough long before clouds.
|
| Also, with AGPL-style license Redis will not become less
| popular. Anyone still will be able to use it as a cache, but
| not as a free work done by others that you can resell without
| contributing back.
| aragilar wrote:
| _Raises eyebrows_ We 're already having the discussion of
| what we should do about redis at work, given it's a cache,
| and the tooling we use allows for other caching tools,
| we'll likely switch away from redis fairly quickly...
| ako wrote:
| Postgres makes for a pretty decent key value cache in
| certain situations.
| rascul wrote:
| > Redis was popular enough long before clouds.
|
| Redis is newer than you think. Or the cloud is older.
| chasontherobot wrote:
| ES was already huge before AWS made everyone think it was an
| Amazon product
| acdha wrote:
| That's highly unlike my experience: each of those tools was
| popular first - the AWS offerings were recognizing widespread
| customer use. You couldn't go to a meetup without someone
| handing out ES or MongoDB stickers by the time AWS decided
| that was a market worth being in.
|
| I do agree there's some value in wider use but developers
| have to get paid. If users are paying someone who doesn't
| contribute much to the upstream codebase at some point the
| project is going to founder. I don't love the change as
| someone who's been using open source for decades but the
| maintainer problem is real and won't go away without
| structural changes.
| blueelephanttea wrote:
| > got wider recognition through AWS's offering.
|
| Other commentators have already pointed out that this is
| probably not true.
|
| But MongoDB relicensed before Amazon could launch a direct
| hosted offering and it is the biggest of all these projects.
| It did not want nor did it need Amazon launching a hosted
| variant.
| ako wrote:
| Aws not offering it does indeed make it harder to adopt,
| especially if you have to have additional billing contracts
| with an additional business party, have to validate their
| certifications (soc2, etc), customer data sharing agreements,
| etc.
|
| There's a difference between developer popularity, and
| ability to actually use it in commercial product. If AWS
| provides a commercial alternative out of the box available
| within existing contracts and certifications, adopting that
| is low friction.
| that_guy_iain wrote:
| I think Sentry's Functional Source License is pretty good.
| That's what I've decided to use.
| sofixa wrote:
| > The right thing to do for AWS would have been to respect the
| work of the original authors (/company) and throw their weight
| behind an offering supported by the original developers
|
| That's what they do in some cases - their managed Grafana and
| Prometheus are a cooperation with Grafana Labs. But it's the
| only one I'm aware of, practically all other ones (MongoDB,
| Redis, Memcached, MySQL, PgSQL, etc.) aren't.
| redwood wrote:
| Look more closely and you'll see that they offer a competing
| service right next to it... it's about the most anti-
| competitive posture you can imagine as they slowly corrode
| their foundation
| hintymad wrote:
| > AWS of course is the single biggest reason why projects are
| flocking to more restrictive licenses
|
| Should be general competition, including AWS, right? AWS does
| not host a Terraform service, yet HashiCorp feels the pressure
| from quite a number of competitors that offer Terraform as a
| service.
| armchairhacker wrote:
| Open-source still has a long-term advantage. Long-term, either
| AWS goes out of business, "enshittifies" their "enhanced"
| version, and/or open-sources it themselves. Meanwhile, the
| open-source version never goes away or gets worse: at worst it
| will bitrot, but that's only if nobody is using it enough to
| put in the bare minimum of maintenance (then when AWS
| inevitably degrades, there's a good chance someone makes an
| open-source rewrite).
| CrLf wrote:
| It's about time we stopped calling projects that require
| copyright assignments "open-source", because they aren't.
| Regardless of license.
| jeltz wrote:
| Agreed, and this is why I never have contributed to a project
| with a CLA.
| lars_francke wrote:
| Not even to e.g. something from the Apache Foundation? Or
| Eclipse? Or CNCF?
| jeltz wrote:
| Yup! I might make an exception at some point but so far I
| haven't. I believe that all contributors should be equals
| and not some have more rights than others. Also I need to
| research and trust the entity which I sign the CLA with.
| jen20 wrote:
| There are two organizations I would consider assigning
| copyright to for free work: the FSF and the ASF, which are
| both organizations with noble goals.
|
| Certainly not the CNCF.
| kelnos wrote:
| All GNU projects require assigning copyright to the FSF[0]. It
| feels a little absurd to call a GNU project "not open source".
|
| But I would certainly trust the FSF not to change licensing
| terms (aside from moving to newer versions of the GPL/LGPL) to
| something unsavory, while the same can't be said of any old
| random project out there. I think that trust (or lack thereof)
| is the real issue. Ultimately, though, it's better to just not
| have to trust; I don't sign over my copyright to projects
| either, unless it's part of a job and the stuff that I write
| would otherwise be owned by my employer anyway.
|
| [0] https://www.gnu.org/licenses/why-assign.en.html
| CrLf wrote:
| The FSF requires copyright assignment so they can upgrade to
| newer GPL versions at will. I happen to disagree with that as
| well.
| littlestymaar wrote:
| The blog post for the announcement: https://redis.com/blog/redis-
| adopts-dual-source-available-li...
| Xenoamorphous wrote:
| What's the actual impact of this for those of us who are using
| Redis in production (not cloud).
| throwaway38375 wrote:
| Same, I am interested to know.
|
| I only install Redis on Ubuntu VMs. I don't pay for hosted
| Redis (since it's always been rock solid for me).
|
| Will these changes stop me from running `sudo apt install
| redis`?
| jeltz wrote:
| Most likely, yes. Debian dropped MongoDB after their license
| change and Ubtuntu seems to have done the same. The last
| version with MongoDB is focal.
|
| https://packages.ubuntu.com/search?keywords=mongodb
| aragilar wrote:
| I think more accurately, yes, but when is more the question
| instead of will it happen. I would expect current LTS to
| keep the open source releases for now (assuming security
| releases for older versions are still released as open
| source, if not you may find it dropped earlier!), but it
| won't appear in any new releases (LTS or otherwise).
| jeltz wrote:
| That your distribution is likely to drop Redis so you will have
| to install it from another repository.
| zokier wrote:
| Has these moves to non-FOSS ever ended up working well in the
| long term? I think for Elastic and Mongo both it hasn't been the
| stellar successes they'd hoped for, those are the two major cases
| on top of my head. Or the big FOSS exodus of Sun projects post-
| Oracle acquisition.
|
| There will be almost certainly some OpenRedis project, but this
| move might just kill the wider community interest.
| WatchDog wrote:
| Dunno about long term, but docker made a bunch of money by
| switching up the docker-desktop licensing.
|
| It's a bit different though, since it was already on a
| proprietary license, and they just changed the terms.
| aragilar wrote:
| Isn't that just the standard Oracle playbook: increase prices
| and push people to alternatives? k8s has long dropped docker
| as a base technology, it really is the dockerhub default that
| makes docker relevant.
| c0wb0yc0d3r wrote:
| That was more because they put a gun to people's head though
| wasn't it?
|
| Docker on windows is pretty painful without docker desktop.
| You can certainly get it running without docker desktop, but
| the polish isn't there. As far as I know there is no way to
| install docker on windows manually and get integration with
| 3rd party tools. The closest I've come is using podman
| desktop. I think it has a way to go before it can be
| considered a drop in replacement
| bit_flipper wrote:
| By which metrics are you evaluating those companies' license
| changes? Both are significantly more profitable than before
| they changed licenses, MongoDB especially. I'm not sure there's
| a causal relationship, but it doesn't seem to have
| significantly harmed them.
| depr wrote:
| Can they do this? Open source contributions to their codebase
| were under a different license. They don't have the copyright for
| those contributions without a CLA (I can't find one). So how can
| they relicense those contributions?
| weinzierl wrote:
| Sure. Only the new contributions are under the new license the
| older contributions are not affected at all.
|
| The follow-up question would be what allows them to still use
| the old contributions together with the new proprietary ones
| and the answer is: the permissive license of the old
| contributions.
|
| If the old contributors have not wanted that, they should not
| have contributed to a project under a permissive license.
| kelnos wrote:
| To be clear (for the GP and others): the consequence of the
| parent's second paragraph is that if the old license were
| something like the GPL, this wouldn't be allowed, unless all
| copyright holders consented to the change. (The GPL
| specifically does not allow "adding restrictions", which the
| new licenses do.)
|
| But since the old license is BSD/MIT (I think?), it's fine.
| BSD/MIT code is still licensed as such, but can be commingled
| with code under the new licenses without issues. BSD/MIT's
| terms can still be complied with under the new licenses.
| rcxdude wrote:
| It was BSD before, which allows relicensing by anyone (though
| they do need to preserve the original notice).
| okanat wrote:
| BSD doesn't allow relicensing. I don't think any license that
| does either. However, BSD allows the licensees to incorporate
| the source however they want as long as they keep the notice
| visible.It doesn't transfer the ownership so re-licensing
| isn't possible.
|
| So basically Redis becomes a licensee of the third party
| contributors and BSD happens to be quite permissive that
| Redis can relicense their own parts while keep using other
| people's creations under BSD without limitations.
| fmajid wrote:
| GPL allows relicensing with any _later_ version of GPL.
| supz_k wrote:
| Slightly off-topic: Until last week, we used Redis for Laravel
| queues and cache in our blogging platform. We decided to get rid
| of Redis and use the database. The reason was that we are
| planning to allow self-hosting of our software so removing a
| dependency is a huge win to reduce complexity (didn't know about
| the license change then). There are a lot of arguments against
| using a relational DB for queues, but from our testing, it _just_
| worked! So, we _just_ went with it in production. Surprisingly,
| there are no noticeable performance issues so far.
|
| We initially used Redis because, well, Laravel recommends it.
| But, what I learned is that Redis is not a requirement until you
| absolutely need it.
| crizzlenizzle wrote:
| Almost three years ago, but the last time we used database as
| engine for Laravel's queue subsystem it exploded due to some
| database table locks under high load. We switched to redis and
| things just worked well.
| petee wrote:
| The link should be updated to either the announcement on their
| blog, or at minumum a specific commit
|
| https://redis.com/blog/redis-adopts-dual-source-available-li...
| lifesaverluke wrote:
| April Fools' Day coming up?
| NathanFlurry wrote:
| Check out DragonflyDB (BSL): https://www.dragonflydb.io/
|
| BSL is not OSI-approved, but it's a much more reasonable AWS-
| resistant license. It's the same license CockroachDB uses, for
| example.
|
| KeyDB (BSL, acquired by Snapchat) is also an option:
| https://keydb.dev/
|
| BSL is a much better license, but it's a gamble on how long KeyDB
| will be supported. I don't want to mess around with such a core
| part of my architecture.
| OPoncz wrote:
| We @Dragonfly had BSL right from start. I think it makes most
| sense for todays infrastructure echsystem.
| fermigier wrote:
| Potential alternatives:
|
| - https://github.com/dragonflydb/dragonfly (BSL-licensed, aka not
| OSS).
|
| - https://github.com/Snapchat/KeyDB (BSD-licensed)
|
| Anyone using one of these?
| fmajid wrote:
| I've tried KeyDB a few years ago, performance was significantly
| better than Redis. Didn;t test the spill-to-disk feature for
| data sets larger than RAM. Not sure if it's kept up with Redis
| on advanced features like HyperLogLog.
| SuperSandro2000 wrote:
| Capitalism does capitalism things...
| externedguy wrote:
| Perfect, yet another reason to use BEAM languages
| codedokode wrote:
| I don't understand what's wrong with AGPL-style licenses. If I
| wrote something that can be used in a cloud I would also prefer
| AGPL to prevent cloud companies from selling software and taking
| all the profit while contributing nothing.
| dspillett wrote:
| _> I don 't understand what's wrong with AGPL-style licenses._
|
| Nothing IMO.
|
| But many commercial entities won't touch software covered by
| them, so if wide adoption is one of your desires this could be
| a significant consideration. You can argue as much as you like
| about where lines are and how using <component> won't mean they
| have to open source their entire business, but you'll get
| nowhere, and the blanket ban will remain. If they really want
| what your component does they'll do it in-house (and maybe
| release that under a more permissive licence) or use an
| alternative if one already exists.
|
| Dual licensing (AGPL with commercial options) usually won't
| help either: they don't actually want a commercial option
| because they don't want to pay for things the way they want
| others to pay their services. Dual licensing can also be an
| issue for other contributors, it becomes more important to have
| a CLA0 so you can do that at all (legally) and a CLA might put
| off a lot of potential contributors.
|
| This would not be an issue for me12, and from your question I
| assume it wouldn't be for you either, but for some
| people/projects it could be more important, possibly a blocker.
|
| --
|
| [0] Unless your project is "open source, not open contribution"
| which is a perfectly valid choice and one I'd likely go for,
| but again this is not suitable for all people/projects.
|
| [1] "We can't/won't use your stuff under its current licence".
| Me: "OK, thanks for letting me know."
|
| [2] "If you don't do X3 we'll have to go elsewhere". Me: "OK.
| Enjoy your trip. Hope it works out for you."
|
| [3] where X could be a license change or anything else
| aragilar wrote:
| AGPL and SSPL are quite different (around how it works with
| other licenses and software), and those differences are what
| makes AGPL still FOSS, and SSPL not.
| devaiops9001 wrote:
| Drop-in replacements for Redis exist. There are two that use TiKV
| as a backend. Microsoft recently released a drop-in replacement
| for Redis.
| oytis wrote:
| I remember in the olden days of open source, when there was a
| debate whether it is viable, the point of the free software party
| was that you are not going to make money selling the software
| itself, but rather using the software or providing support for
| it. Later at some point as open source matured, some people
| decided it was still possible to make an open source business.
|
| I think by now it is more or less clear it is not the case - the
| companies that _use_ open source to support their non-software
| core business are the ones that take most of the pie. There is as
| little reason for outrage as for surprise in my opinion.
| tinco wrote:
| OSI lost touch with their mission. This SSPL license is clearly
| an open source license in the full spirit and original intent of
| open source. It is more aggressively copyleft than AGPL is.
|
| Their reasoning[0] for not considering it open source is that due
| to the requirement that all interfacing software (my words) must
| also be open source it restricts the possible fields the software
| can be used in. Reread that sentence! that's exactly the intent
| of the original GPL license, and follows directly from the
| philosophy of its progenitor.
|
| If the original GPL was proposed today, then following this
| reasoning the OSI would not have approved it. Imagine today the
| Nginx project would switch its license from MIT to GPLv2. Just
| regular old GPLv2. Would the OSI also complain that previous
| contributors thought they were contributing towards the "greater
| good" and now their software is embedded in a proprietary
| product, just because nginx plugins now have to be open source as
| well?
|
| The OSI shouldn't be chasing some vague "greater good". They
| should be protecting the spirit of open source. Which includes
| copyleft licenses like GPL, AGPL and SSPL.
|
| [0] https://opensource.org/blog/the-sspl-is-not-an-open-
| source-l...
| redwood wrote:
| I think you have it right. Unfortunately much of the "OSI is
| OS" commentariat misunderstands the SSPL which aims to confer
| freedoms to use with no obligation from there (and even deliver
| as a public service where the machinery that does so is also
| made open source and hence free for others to use).
|
| If the OSI calls the AGPL open source, surely the SSPL is as
| well. A lot of people seem to lose the forest through the trees
| on "free as in freedom" vs "free as in beer" to the extent that
| copyleft offers a sustainable road to free as in freedom for
| the community... Unfortunately zealots have shot themselves in
| the foot without realizing they're doing the strip mining
| hyperscalers' bidding.
| weinzierl wrote:
| If the SSPL is more aggressive than the AGPL why don't
| companies just adopt the AGPL. This is an honest question. I'm
| familiar with the AGPL but not with the SSPL and wondered
| before, why the AGPL is used so rarely.
| redwood wrote:
| Because the AGPL left more ambiguous the scenarios where the
| user would be compelled the open source their work that used
| the AGPL licensed work: this unfortunately led many people
| and organizations to rule out the use of a AGPL software.
| Google and Amazon in particular are known to have these carte
| blanch rules in place.
|
| While an open source maximalist might be happy with that
| ambiguity, if it impedes the use of the software and hence
| the chance that a broader community of open source will
| thrive, it arguably backfires... SSPL aims to make explicitly
| clear that it is in context of building a public service for
| the software that the copy left provisions of an expectation
| of open sourcing occur.
|
| The theory is that this allows the software to be more widely
| used and for the community to benefit when a public service
| open source project is maintained
| bawolff wrote:
| The goal of these license changes is to prevent people from
| selling Redis as a service essentially, in order to prevent
| them competing with the redis company's offerings. If it was
| AGPL, you would still be allowed to do that.
| blueelephanttea wrote:
| MongoDB was AGPL. They decided it was not sufficient to
| prevent an Amazon hosted MongoDB offering so they went down
| the path of SSPL.
| RobotToaster wrote:
| The problem is the entire stack has to be released under the
| SSPL.
|
| Which means if you want to offer it as a service, you can't use
| it on GNU/linux, since you don't have permission to release it
| under the SSPL.
|
| edited to add: this could easily be remedied by simply
| requiring the entire stack to be published under either the
| SSPL _or an OSI /FSF approved license_. Such a license
| (somewhat ironically) probably wouldn't be approved by the
| OSI/FSF, but it would solve the main issue with it. Although I
| also suspect the people using the SSPL consider this a "feature
| not a bug" of their psuedo-open-source licence.
| u320 wrote:
| How can it be used at all under SSPL then? There are no
| operating systems on which Redis runs that uses that license.
| RobotToaster wrote:
| You only need to do that if you operate it as a service
| that you sell or give away to others (rather than just
| running your own internal redis instance)
|
| So yes, this basically prohibits anyone but redis from
| operating it as a service, unless you write your own
| operating system for it to run on. (Although presumably
| they will sell you licences or similar to operate it as a
| service)
| aragilar wrote:
| That's why it's dual licensed.
| bawolff wrote:
| That's essentially why people think its not-free. In
| essence, it pretends to give you the right to do something,
| but puts impossible to meet requirements so that in
| pracitise you cannot do the thing.
|
| In essence, the license says you cannot use it as SASS
| software, but they didn't want to outright say that, so
| they did this instead.
| cvalka wrote:
| That's the point! It's impossible to comply with it. If it
| were an open source license, it'd require every component
| to be released under an open source license.
| redwood wrote:
| I don't believe that was the intent. If you look at the text
| it's more focused on the unique software that goes into
| delivering the service itself ... but since the goal of the
| SSPL was in many ways to reduce ambiguity compared to the
| AGPL, I think this perspective should be reflected upon and
| perhaps incorporated into a future version of the SSPL.
| e12e wrote:
| Let's say you deploy a work queue service backed by Redis,
| with authz/n delegated to Azure AD. You would require a
| commercial license since you can't publish Azure AD?
| redwood wrote:
| A work queue service is not a public Redis service so you
| have total freedom to do whatever you want in this case
| tormeh wrote:
| Isn't SSPL compatible with the GPL? If so you could "just"
| republish your stack under the new license. Not sure how
| feasible this strategy is in practice, as any company's stack
| is vast and no one wants to enumerate it all...
| cowsandmilk wrote:
| > Isn't SSPL compatible with the GPL?
|
| Not sure how that could be the case. SSPL places additional
| restrictions on the usage of the software, so you cannot
| relicense GPL code as SSPL.
| maffulli wrote:
| OSI executive director here: The SSPL was retracted from review
| (it was years ago) as the discussion on a mailing list stalled
| and became unproductive. Read the original threads on the list,
| not just that blog post. Frankly, it was a low point for the
| organization, the board at the time recognized it and that
| triggered a structural change[0], too.
|
| We've been thinking about how we'd discuss large and
| controversial licenses in a productive way. We're learning how
| to drive large, productive, difficult conversations with the
| process towards the Open Source AI Definition[1] and we hope
| (soon) to be able to transfer that knowledge to other pressing
| issues, like complex licenses.
|
| [0] https://opensource.org/blog/osi-executive-director [1]
| https://opensource.org/deepdive
| cipherboy wrote:
| Does this also extend to the BUSL?
| maffulli wrote:
| I don't think anybody would argue that the BUSL is an open
| source license. OSI has investigated and released a report
| last year about the business practices similar to what the
| BUSL uses: https://opensource.org/delayed-open-source-
| publication
| tinco wrote:
| Thank you, and it's great that it was recognised a structural
| change was needed inside and that they attracted you to help
| implement that. I understand there's deep and long threads on
| the mailing list, and that there are great flaws with the
| SSPL.
|
| That the communication with MongoDB crashed and left a sour
| after taste I can imagine. But the fact now is that there's a
| deeply flawed SSPL out there, OSI's only real public
| statement is very dismissive of it. It does not address at
| all the concerns of Elastic or MongoDB, painting them as some
| sort of bad guys, when in fact their products have always
| been open source, even when they were so valuable they really
| didn't need to be.
|
| And the companies that drove them away from what OSI
| considers open source, are OSI's two biggest sponsors! Two
| sponsors it is worth mentioning, who built their products
| entirely as proprietary closed software, on top of open
| source software.
|
| So now, wether they meant to or not, OSI has profiled
| themselves as defenders of proprietary platforms, making no
| effort to acknowledge the plight of open source companies,
| and lost credibility to such a degree that now again one the
| great open source companies has dismissed their approval and
| went for an unapproved license.
|
| If the OSI was really serious about the "greater good", they
| would have worked with the FSF and helped MongoDB, Elastic
| and Redislabs defend against proprietary platform companies
| such as AWS and Google with an AGPLv4 that has the provisions
| the SSPL introduced without causing the concerns other people
| raised in this thread with regard to (possibly intentional?)
| vagueness around what does and does not need to be open
| sourced.
|
| If that had happened, then maybe today Redislabs would have
| announced their switch to an OSI approved open source
| license, and the OSI would have retained its legitimacy and
| reputation. How many great budding open source/open core
| projects have been inspired by the success of Redis, MongoDB
| and Elastic, that now will consider the same path as these
| companies, or worse, that of Hashicorp?
| PeterZaitsev wrote:
| What I would rather see from OSI is defining Source
| Available licenses better.
|
| MongoDB, Elastic, Now Redis do not really provide the
| practical freedoms one comes to expect from Open Source
| software - it is clearly anti competitive by design which
| is bad for the use who will suffer bad quality and inflated
| prices as you always do when monopoly is created.
|
| Having said that Source Available Licenses are better for
| end user in many circumstances than old fashioned
| Proprietary licenses and spliting the world in black and
| white does not help
| tinco wrote:
| I'm not familiar with the Elastic ecosystem, but both
| MongoDB and Redis have a great plenty of competitors,
| many of which implement the same wire protocols even,
| that don't make use of their license at all. So I don't
| think symmetric competition is affected or even a concern
| of these companies. Symmetric competition still drives
| them to improve quality and pressure prices.
|
| It's the asymmetric competition from the platforms that's
| siphoning resources from these companies that could have
| been spent on improving the core product.
|
| I don't understand your point with regards to Source
| Available licenses. Sure, source available is beneficial
| to the end user, but what does that have to do with open
| source licenses and the OSI? Source available licenses
| are simply irrelevant. If source available licenses need
| representation there should be a new organisation formed
| for them, no need to involve the OSI. You could call it
| the Source Available Initiative.
| maffulli wrote:
| > What I would rather see from OSI is defining Source
| Available licenses better.
|
| Let's have a coffee and you can explain to me why you
| think this would be useful. I'll email you.
| maffulli wrote:
| I don't accept that this is OSI's fault thought: It takes
| two to tango. The OSI has been thinking about a more
| appropriate format to address the issues of copyleft in the
| cloud world. I recognize that the problem exists, I wrote
| about it here: https://opensource.net/lost-decade-crucial-
| lessons-for-ai/
|
| Frankly speaking, I would love to see also a detailed
| criticism of the AGPLv3. I would love to have a better
| understanding of why the SSPL was deemed necessary and what
| needs the AGPLv3 fails to satisfy... So far, the only
| explanations I've heard are superficial at best.
|
| You have to also realize that most of these companies are
| not interested in copyleft or in the values of Open Source
| to empower users. They're following a very well known path,
| one that Phipps calls the rights ratchet model. Call it the
| SugarCRM model, if you prefer: it's a very very predictable
| pattern, from Open Source to proprietary in about 10 years
| https://meshedinsights.com/2021/02/02/rights-ratchet/
|
| These are complex matters though and I'm convinced that
| they cannot be eviscerated properly on a social media, or
| only on an online forum. We need better ways.
| tinco wrote:
| You're right, I don't want to imply it's OSI's fault at
| all. There is an incentive from the ex-opensource
| companies to move on from their permissive licenses to
| something else. That movement is entirely separate from
| OSI, the best OSI can do is entice and encourage project
| to go or stay open source. You can take a horse to water,
| but in the end you can't make it drink.
|
| I agree that the companies are not really interested in
| copyleft. They built a business on open source, and as
| they gain popularity the edge they have in competition by
| virtue of being the original authors of the project is
| eclipsed by the resources and marketing power of platform
| operators. They turn to copyleft to ensure the platform
| operators can not use their superior resources to
| embrace, extend and extinguish their product. They use
| copyleft to even the playing field, and maintain their
| profit margin.
|
| And yeah there's the ratchet. I think it's in the open
| source community's interest to try keep projects inside
| the "open" part of the ratchet cycle. I imagine that if
| there was an AGPLv4 that had more of the SSPL style
| provisions it could've kept Redislabs inside the "open"
| part of the ratchet for another 5 years.
|
| With regards to a detailed criticism of the AGPLv3, the
| SSPL is a straight fork with a small diff, which
| basically amounts to rewriting section 13. I feel it is
| really clear what the intended effect of the changes is,
| what do you think the OSI could learn from a more
| detailed criticism? The goal is that platform companies
| can no longer use proprietary software to operate their
| product. That might be superficial, but I just don't see
| a reason why it would have to go deeper than that.
| jimjag wrote:
| How a license which conflicts with the OSD can "clearly (be) an
| open source license in the full spirit and original intent of
| open source" is beyond me.
| bawolff wrote:
| > OSI lost touch with their mission.
|
| Its hardly just the OSI. Debian, redhat, FSF all think this
| license is bad.
|
| > Their reasoning[0] for not considering it open source is that
| due to the requirement that all interfacing software (my words)
| must also be open source it restricts the possible fields the
| software can be used in. Reread that sentence! that's exactly
| the intent of the original GPL license, and follows directly
| from the philosophy of its progenitor.
|
| When they say "all", they really mean "all". The exact phrase
| is: " including, without limitation, management software, user
| interfaces, application program interfaces, automation
| software, monitoring software, backup software, storage
| software and hosting software, all such that a user could run
| an instance of the service using the Service Source Code you
| make available."
|
| IANAL, and its not 100% clear, but i think this would prevent
| for example, using redis on a windows server because windows is
| not open source. What if the hard drive you are using has non-
| free firmware? Is that allowed? I don't know, but the fact its
| even a question seems ridiculous here.
|
| In essence, I think this clause is so burdensome, that nobody
| could realistically comply with it. Thus the license effective
| disallows that specific purpose. So I agree with OSI's
| assesment.
| tejasbaldev wrote:
| If anyone is still debating about fairness, philosophical view
| point, business viability of OSS projects, competition from cloud
| providers - please click on the link below and check it for
| yourself.
|
| Link - https://docs.aws.amazon.com/AmazonElastiCache/latest/red-
| ug/...
|
| Context : Redis Inc (fka RedisLabs) started creating ''Redis
| Modules'' later known as Redis Stack to start differentiating
| with cloud provider's managed Redis. The idea was to keep Redis
| Core BSD licensed (one of the most liberal licensing model) but
| at the same time build a layer on top of this BSD layer to keep
| differentiating the service.
|
| One of these modules was Redis JSON which allowed you to use
| Redis as a JSON store. One cloud provider copied the whole
| codebase (even though it was protected by all the licensing
| clauses) and it doesn't stop there. JSON.FORGET was a cool
| command created by one of the exes at Redis & the ''cloud
| provider'' ended up copying that command as well!
|
| If you're still debating whether a company should continue with a
| liberal licensing like BSD only to allow cloud providers or other
| service providers to blatantly plagiarise the codebase, think
| again.
| lmz wrote:
| If there was a license violation they should sue. Otherwise,
| writing a compatible reimplementation of something should not
| be something "open" fans are against.
| sofixa wrote:
| I think OP's point is that AWS have the resources to
| reimplement all the differentiation you can try to add with
| an open core model like Redis tried, which makes the whole
| attempt at open core useless. Therefore the choice is either
| to try to partner with AWS like Grafana Labs managed to do
| (only ones I'm aware of), move to a license with restrictions
| on them reselling your code, or accept defeat.
| lmz wrote:
| Well even if they moved to a restricted license it would
| not stop reimplementations of the same protocol (I assume
| the extra non-open-core bits were already under a more
| restrictive license). I think that was just a poor example.
| tejasbaldev wrote:
| Good luck with suing a ~2 Trillion USD marketcap company. It
| will drain all your resources to a point of no return.
| opeon wrote:
| Explanation from Redis themselves https://redis.com/blog/redis-
| adopts-dual-source-available-li...
| hobabaObama wrote:
| > Explanation from Redis themselves
| https://redis.com/blog/redis-adopts-dual-source-available-li...
|
| I am sorry, isnt this the post itself? Or am I missing
| something?
| captn3m0 wrote:
| For those worried about EOL, Redis 7.4 will be the first release
| under the new license, leaving 7.2 as the last release with the
| old one. Redis supports 2 additional releases at a given time:
| latest major.(minor-1), (major-1).(last-minor).
|
| This roughly means that 6.2 will go out of support once 8.0 is
| released, and 7.2 will go out of support once 7.6, or 8.0 is
| released.
|
| Looking at prior releases, my guess would be to expect a 8.0
| release around Mar-May 2025. So if you're relying on Redis under
| the 3BSD license, plan accordingly.
|
| Note that Ubuntu packages redis under the `universe` repo, which
| means security upgrades are only available to Ubuntu Pro
| customers. So Ubuntu 20.04 will stop redis upgrades on Apr 2024,
| except for Ubuntu Pro users under ESM.
|
| Debian 11/12 track Redis 6.0/7.0, so they are responsible for
| backporting the patches from 7.2. Unsure how this will happen
| once 7.2 stops receiving security updates, and they only go to
| the 7.4 branch.
|
| Also note that you might be impacted indirectly (even if your
| usage of redis fits with the new license), because your distro
| will likely drop redis from its official repos in the next
| release, so should account for that in the next distro upgrade
| cycle.
|
| (I maintain https://endoflife.date/redis, happy to merge PRs if
| someone has clarity on how this might impact EOL/Support)
| frontalier wrote:
| Redis is still 'free as in beer', unless you are operating a bar
| and want to profit off of the free beer someone else produced,
| then it's not 'open source', but somehow you can still get the
| source as it remains 'source available'.
|
| Did I get it right?
| mythz wrote:
| Good, most value in OSS is being syphoned off by the mega corp
| cloud vendors which contribute nothing back to the maintainers of
| the OSS products they're charging rent for.
|
| That's not a sustainable relationship for a healthy OSS product,
| mega cloud corps rake in most of the profits whilst the
| organizations maintaining them have to handle the burden of
| increasing customer support issues and developer wages.
|
| The SSPL aka "Free for all, except cloud corps" License should be
| more common place.
| byyll wrote:
| Great change. Should have been like that from the start but would
| have probably impacted their growth.
|
| Any company can still use Redis for their needs, only leeches
| like AWS can't.
| theanonymousone wrote:
| Why isn't Affero GPL used in such cases? Isn't it designed
| exactly for such scenarios?
|
| Wikipedia link:
| https://en.wikipedia.org/wiki/GNU_Affero_General_Public_Lice...
| shantnutiwari wrote:
| As usual, the comment section is full of entitled people whining
| about "muh open source".
|
| Like others have said, OSI definition of open source is very
| outdated and needs to be updated.
| xenago wrote:
| Most people must know that redis inc didn't create redis right??
|
| https://en.wikipedia.org/wiki/Redis_(company)?useskin=vector
|
| It's funny and hypocritical that a corporation, which used the
| very terms of the license they now seem to hate in order to come
| into existence in the first place, is closing that exact path
| out.
| PeterZaitsev wrote:
| Do not kid yourself SSPL is intentionally designed so even
| someone who wants to provide DBaaS version and honestly
| contribute to the project can't really use it, because most
| likely I can't SSPL all components which are required
|
| Imagine I'm independent provider looking to compete with MongoDB
| Atlas and ready to Open Source everything I need. But oh wait - I
| have S3 as my Control plane, EBS, AIM etc - none of which I have
| option to Open Source.
| redwood wrote:
| As I said in another comment, I believe this is a fundamental
| misunderstanding of the intent, but hearing you and others
| saying it shows that the authors will need to consider further
| revisions.
| whaaatttttttzzz wrote:
| Does this mean that Redis will no longer be shipped in Linux
| distros?
| bionhoward wrote:
| 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.
| PeterZaitsev wrote:
| 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.
| Dylan16807 wrote:
| > 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.
| marklar423 wrote:
| 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.
| Dylan16807 wrote:
| > 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.
| mirekrusin wrote:
| Open Source has a) you guys implement it b) we sell it 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.
| miraculixx wrote:
| Wait, no. You can't run it for anything commercial unless you
| pay up. That's their whole spiel.
| thtmnisamnstr wrote:
| I work at Earthly. We build a pretty popular open source build
| tool. I've worked for several companies that build OSS before
| Earthly as well.
|
| At Earthly, a few years ago, the founder and CEO had these same
| concerns about big cloud providers and switched to a source
| available license. There was backlash, and after around a year,
| we switched back to open source. We've discussed things like this
| a lot, and believe an open source license is best for our
| product, our users, and our business.
|
| The way that we differ from Hashicorp, Redis, and others that
| have switched to source available licenses is that the service we
| offer and generate revenue from isn't just a hosted version of
| our OSS. It's several services that natively integrate with our
| OSS but are not open source. This seems like one of the only ways
| a company that maintains popular OSS can survive without
| switching licenses: build great OSS that users love, build non-
| OSS services that integrate with and augment your OSS (and/or
| open up new use cases), and charge for those services.
|
| If the service a company sells is just a hosted version of their
| OSS, even if it has a bunch of non-OSS bells and whistles added
| on, that company is at risk of a cloud provider eating their
| lunch unless they switch to a non-OSS license.
| mirekrusin wrote:
| Am I the only developer, working for corporation that is using
| other mega corp's cloud, using redis personally and at work - who
| sees this as good news?
|
| This change means that cloud providers will have to share premium
| they're charging customers for offering redis as cloud service.
|
| Developers still have access to source code, you can use it
| personally and for commercial products, you can use it on your
| cloud VMs, dockers, k8s etc. as before.
|
| The only affected parties are competing cloud providers - they'll
| have to share their premium.
|
| What's wrong with that?
|
| Sounds like solid way to build sustainable business around open
| code.
|
| Also putting together all this other stuff into single package
| (JSON, vector, probabilistic and time-series) sounds great!
| acdha wrote:
| > Sounds like solid way to build sustainable business around
| open code.
|
| Yeah, that's basically my question: how else do they make
| money? I'd bet that there's at least one order of magnitude
| more people who use any of the major cloud providers' hosted
| Redis service than who pay for a support contract, and probably
| at least two orders more than contribute anything substantial
| to the open source project. At some point you need recurring
| revenue or development is going to slow dramatically.
| NelsonMinar wrote:
| Possibly relevant: Redis Contributer Copyright Assignment. This
| dates at least to 2022. https://redis.com/legal/redis-software-
| grant-and-contributor...
|
| I get why Redis would want every contributor to sign this
| agreement. What I don't understand is why any open source
| contributor would agree to sign it. Maybe because someone is more
| interested in getting their contribution integrated than having
| any say over future licensing of their work?
| gregors wrote:
| The problem is that the idea was "we'll build this nice thing and
| other people who use it en masse will also be nice and give us
| some money for support or just because"
|
| The reality is large places will take as much as they can and
| never give anything unless forced into such a deal. Open source
| tech is probably tainted in this regard. How many other projects
| have gone this route for basically the same reason?
|
| I hope this means large tech will actually contribute some money
| to Redis. I've used Redis for many years and hope they can make
| some money after giving so much away for so long.
___________________________________________________________________
(page generated 2024-03-21 23:01 UTC)