Redis is now available under the AGPLv3 open source license (Redis blog)

9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program.

You left out "and then proceeded to operate it on a public road in a manner that gave a law enforcement officer probable cause to initiate a traffic stop". You can [ab]use it all you want in private property.

> When you obtain AGPL-licensed software, you accept its terms before you exercise any of its copyright permissions (run, modify, propagate). That means any licensee who runs a modified version over a network implicitly agrees to §13’s conditions, even if they weren’t the one who wrote the patch

Nope, you are quite wrong. The AGPL terms only kick in for those doing the modifying, because the license *explicitly* states: "You are not required to accept this License in order to receive or run a copy of the Program." (AGPLv3 section 9), and "if you modify the Program, your modified version must prominently offer...." (AGPLv3, section 12). Meanwhile, with respect to merely "running", 17USC117 states that it is not infringement provided that "such a new copy or adaptation is created as an essential step in the utilization of the computer program"

The requirement to add (or preserve) an in-band source code distribution mechanism falls solely on the party that modifies the software, The recipient of that modified version doesn't have to accept the AGPLv3 to merely receive or run it (again, see the plain text of the license and the law), so if they don't further modify what they received (beyond "essential steps in the utilization of the program") they're not bound by section 12's requirement to provide an in-band offer of source code *if one doesn't already exist*

Cost for administrators is indeed an often repeated argument. But what company has actually let go of a significant part of their IT team after migrating into the cloud? Conversely I don't know of any company that had to hire additional personnel after moving away from a hyperscaler.

Even if, one of my customers pays about a million USD per year to Google. Buying the required hardware to run the whole shop would cost about 300k once. Even with rented boxes in a data center and on-site service by the great people at firstcolo this customer could save a staggering 90 % of cost[1]. How many competent sysadmins can you get for that kind of money and still save a ton? In this region 100k per year is a super competitive salary for this job. Get 3 of them and still save tons. Or don't and instead hire one of the plenty of IT service companies (like mine).

> Yes, that's precisely that “10,000 lemmings can't be wrong” thing, but it's also the real reason cheap ad-hoc solutions are not used

That is indeed the core of the problem: people coming from universities nowadays only know the world where you run your k8s pods at a hyperscaler. That's what they learn how things are just done and for them there's no point in questioning this. For them, that's the only world that exists. Even so, it's not yet too late to turn around.

[1] You may wonder why they don't. Case of bad timing. Shortly before I became aware of their enormous cloud cost they signed a deal with Google for 3 years for a few percent rebate.

Because you can train up USERS very easily to be developers - as an alleged end-user I'm expected to program as part of my job. So you don't need to hire-and-fire because they're users who can program, not surplus programmers. I'm expecting my colleagues to find Pick *much* easier than what they do at the moment ...

Because jobs come in ON TIME and UNDER BUDGET? Our current "big project" - finally going live this year - has been "two years away" for the last five years - which seems to be the norm for big relational projects? We've been told we'll have to wait 18 months before IT will even look at our little project - I've been threatening to write the whole system single-handed in 6 months. Etc etc.

Because it'll halve the cost of your IT department? What little information there is says that a Pick shop pays roughly half the percentage of gross turnover on IT than other shops do.

It's "Nobody got fired for buying IBM" all over again.

Cheers,
Wol

At risk of committing an act of necromancy, I'll disagree a bit here. There are a lot of no-sql tools with different paradigms which didn't exist 10 or 20 years ago and that one couldn't assume any new hire would be familiar with that they'd have to learn on the job. New hires are going to need to learn the particulars of your tech stack and in-house tools, so learning a different DB engine then one they've used before is probably not an insurmountable challenge. Using the most common tools in hopes of making hiring easier is fine as far as it goes, but so does using best-of-breed tools that fit your particular problem set and expecting some amount of in-house training/acclimation.

That said, I'm not sure where Pick would fall into this, while I'm sure it is innovative in it's own way, and has it's own cheerleaders (hi Wol) I don't think it represents some hidden arcane field of computer science that doesn't exist in equivalent forms in other tools. There are only so many different ways to make efficient data structures in memory or on disk that have different tradeoffs. The no-sql evolution was about offering tools using specific data structures that fit well with the problems they were solving but weren't commonly available or efficient in SQL-fronted database engines, because SQL servers were targeted at different problems. I'm not sure that's the case anymore, the SQL-fronted engines like PostgreSQL or MariaDB have added storage and indexing methods which offer some of the same data structures which made no-sql engines useful, and the other no-sql engines have thrived in their niches refining the use-cases which spawned them. I'm not sure Pick would be any different than someone coming from PostgreSQL learning Redis/Valkey or someone familiar with Cassandra learning sqllite or etcd

So building a tech stack for hire-ability seems foolish, it's one property among many and if you hire for competency and willingness to learn then they can pick up the specifics, familiarity with more components of your stack is nice but lack of familiarity with one component is not a deal breaker.