Redis change licence type

Discuss
,
1

Hi
i see that Redis licences Change, we are an impact change on Yunohost ?

2

(Answering as an individual and not for all YunoHost contributors)

Obligatory not a lawyer: as per point 17 of their FAQ, there is no impact on YunoHost. Though I think we should evaluate if we do need Redis integrated by default, and we should display a statement somewhere that reminds people of that license (especially for the ones building their business around distributing YunoHost).

4 Likes
3

To be seen also how things evolve in the future regarding wether or not Debian will continue to ship it (I’m guessing no because Debian doesn’t like SSPL, same story as MongoDB and Elasticsearch), but right now Redis is available in Bookworm and even Trixie (Debian 13) so I don’t think it’s gonna impact things before at least 3-4 years, and by then maybe Redict will be the new drop-in replacement idk

4

They changed the licence once, they have the ability to change it to an even more restrictive one. Don’t trust someone who betrayed you, he’s capable of doing it another time.

5

It’s not as simple as “they changed the licence to non-OSI-one, they must be bad guys” !

The SSPL was created by MongoDB after realizing that Amazon were effectively selling MongoDB SAAS without contributing in return. Effectively you end up with having to choose between essentially :

  • keep your software as FOSS, but megacorps will use it to earn money from your work without contributing back
  • OR tweak the licence to prevent megacorps using it (or force them contributing back), but it won’t be FOSS anymore and FOSS folks will be complaining.

Who can really blame them for picking the second option ? FOSS has a fundamental, unsolved flaw of having nothing to say with respect to effectively funding large project. In fact I’m curious about what are projects who found sustainable and ethical plans to keep the boat afloat economically speaking (NB: relying on the work of dozens of volunteers ain’t really ethical nor sustainable). For example, Mozilla’s funding is 50%+ coming from Google, which on one hand raises many question regarding how “free” they are to design Firefox especially regarding privacy-related or ad-blocking features, - on the other hand : good luck finding a model to get the hundreds of millions every year needed to keep Mozilla alive ¯\_(ツ)_/¯ 


Anyway, back to Redis and the SSPL : keep in mind that right now in the catalog, we have other apps relying on MongoDB and Elasticsearch, which are already licensed under SSPL. To me it just looks like there’s a trend and FOSS folks should really start to wonder how sustainable FOSS projects are in a capitalist world

8 Likes
6

Does someone have a summary of what changed ? I’m having an hard time figuring it out


I only mean the facts, for instance what can no longer be done now, what couldn’t before but can now, if that open new possibilities for licensing changes or stuff like that


7

What changed is that Redis is now licensed under the SSPL, which is basically the AGPLv3 (which already says "you must release any modification of the program), with the addition of a somewhat “aggressive” clause that says :

[entities] 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.

Basically this is something created to disrupt the ability to simply “pick the software for free and sell it as SaaS on an online platform” (cf the story of MongoDB vs Amazon), because then you have to release the code source of everything which probably is not good for the commercial activity.

The SSPL was not accepted as an open/free license by the FSF nor the OSI because basically it restricts the usage of the software (though basically only for commercial entities, so doesn’t change anything for the average self-hoster
)

People therefore end up saying that it is a “proprietary” license, which is honestly kind of funny considering it’s also “copyleft”, but FOSS folks only see license in binary terms, it’s either “free” or “proprietary”, which leads to stupid stuff like “The ACSL is not free software therefore it is proprietary” like yeah 
 those licenses just try to solve the problem that commercial entities should not be able to simply earn money by just git-cloning a software and slapping a payment interface on top of it without ever contributing back

(I could rant about this for hours x_x)

6 Likes
8

Not to start anyone on a paranoid track here, but would any entity benefit from stoking that sentiment?

9

There is an official statement from the OSI about SSPL:

10

Yeah to me that’s just plain boring and it sounds like they did not ask themselves why Mongo and Elastic went to the SSPL in the first place 


Outside contributors donated time and energy with the understanding that their work was going towards the greater good, the public software commons. Now, instead, their contributions are embedded in a proprietary product.

cf my previous message, people are like “oh if it’s not FOSS therefore it must be proprietary” 
 and there’s some sort of dogma that “FOSS is for the greater good, and only the OSI or FSF definitions of FOSS are the for the greater good, everything else is evil”.

One could also argue that “outside contributors” probably did not expect that their free work would be used by FAANGS and other capitalist entities to print money. Hell, FAANGS are literally built on top of a mountain of FOSS project, then they just wrapped their proprietary stuff on top and created surveillance capitalism, probably for the “greater good” 


I’m really wondering how can somebody demonstrate out of the 4 free software freedom that only respecting those 4 freedoms allows “greater good”. All I see is 3 developers freedoms (so not “regular people”), and only one actually about users (freedom to use the software for any purpose, no condition). Yet bombs running on FOSS do not free people. And somehow people should be “free to use the software”, but accessibility is a real issue, and it’s not uncommon to see proprietary solutions being effectively more accessible than FOSS ones.

Elastic’s relicensing is not evidence of any failure of the open source licensing model or a gap in open source licenses.


 except the Amazon/MongoDB the story that they don’t mention, and wouldn’t be surprised there are similar ones with Elastic

It is simply that Elastic’s current business model is inconsistent with what open source licenses are designed to do.

It’s easy to say “just find another business model”, but my understanding is that the very nature of MongoDB, Elastic and similar project is that it makes sense to create commercial SaaS out of it
 ?

If an artist creates an awesome piece of art and release it using a fully open license, and then some big company use this without asking and makes millions out of it, then are you really going to say “oh you should find a better business model” ? Fun fact there’s the CC-no-commercial-use for that kind of case, which is also considered “not FOSS-like”, same situation :person_facepalming:

I really wish some smart people could just sit around a table and deconstruct the dogma around FOSS being supposedly the only form of “ethical software”, and find something to go beyond the stupid status-quo of “don’t take away our right to freely use your work, but it’s *your* job to find a way to make money to eat!”

6 Likes
11

Ok, I understand it like that.

Then in my view this isn’t harmful for the end users (which is the whole point of free software, people freedom as in emancipation), because it prevents another company to take the code and sell a closed source service or something like that. If it’s also protecting the business model that make the software available for free (as in free software), I wouldn’t see why this could be an issue


1 Like
12

I don’t know much about Redis’ history, the company or how complex the whole thing is as software in the end. I do know a fair bit about FOSS licensing and governance though.

This became long, so I’ll try to make some order with headings.

Also, Aleks, I’m not trying to pick a fight with you, just quoting you to keep the continuity of the thoughts flowing.

OSI, definitions etc.

I’m not member of the OSI (was member and employee of FSFE though), so can’t talk about their position. But knowing several key members there as well as being part of their licensing mailing lists and, I can assure you they know about the FOSS funding issue (DB or otherwise) and they are thinking about it.

OSD and the FS definition are something that exists and have worked for decades. There are occasional talks about changing them and these are taken seriously, but it’s also important not to throw away the baby with the bathwater when doing something as big as change a definition so many people rely on.

The good news is there are smart people sitting down and discussing this. I have participated in and even organised some of those gatherings. But it’s not an easy problem to begin with, and trying to not break things makes it even harder. Imagine if the OSD or FS definition changed and fixed this backend-as-a-service problem, but it pissed off half of the community. Imagine the schism that would ensue – and we just kind of mended the FS vs OSS schism.

SSPL analysis

I’ll keep it short, so people don’t fall asleep. So I apologise for the terseness.

As mentioned before the biggest change is in SSPL-1.0 §13 (emphasis mine):

  1. Offering the Program as a Service.

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.

§13 is also made even more important as it is explicitly called already in §2 Basic Permissions

But there is a much smaller, but equally important change in SSPL-1.0 §12 (emphasis mine):

  1. No Surrender of Others’ Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot use, propagate or convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not use, propagate or convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

As a result, the issue is not just with Freedom 0, (arguably OSD5) and OSD6 caused by the change in §13, but also the question how to apply the changed §12 “liberty or death” clause in practice.

The scope of the copyleft clause – what else needs to be shipped with source code is much broader than under the (A)GPL. SSPL-1.0 namely requires (emphasis and square brackets mine) in § 13:

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces [APIs], 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.

  • minimalistic interpretation: as long as a package that was used unmodified in order to make the Program (or its modified version) run as a service is generally/publicly available FOSS, it does not fall under “Service Source Code”.
  • maximalistic interpretation: you need to provide all the “Corresponding Source” for all the packages that were used to make the Program (or its modified version) run as a service, minus “System Libraries”, and “general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work”.

And the maximalistic interpretation is one that several FOSS license experts (publicly, e.g. Van Lindberg) have pointed out as potentially impossible to fulfil.

FOSS devs need to eat too

I absolutely agree that FOSS development needs a way to survive and thrive. There are many challenges when it comes to making FOSS development and maintenance sustainable, and it’s a hard problem that has many facets – legal, economic and societal – and for all it shakes some long-established (quasi-)foundations such as copyright and consumer capitalism.

Absolutely! And oddly enough, this plays well into one of the counter-arguments: what makes database systems so special and different from the rest of the server stack, starting with Linux, GNU tools, 
 or all the permissively-licensed projects, for that matter?

You don’t hear Postgres and SQLite threatening to change their licenses.

(I am playing a bit of a devil’s advocate here, but only half)

I’d separate this into two problems, if I may.

General problem

One is the general problem of funding FOSS development and maintenance. This is a field several smart people – Carlo Daffara as one of the earliest researchers – are looking into and it’s clearly changing (SaaS was one such change).

Setting up a business plan is hard as it is and doing it to support your FOSS, which you give to everyone for free makes it a bit harder still – you need to figure out what you can charge for th (and you probably need to re-evaluate this every few years)

One needs to take into account that many small businesses / startups and independent businesses don’t survive – FOSS is here not an exception, really, as statistics have shown.

Some FOSS-compatible business models – some more, some less FOSS – that businesses tend to use and mix’n’match:

  • selling support & maintenance (& QA)
  • dual-license – i.e. same software under a (strong) copyleft license and a proprietary license for those who don’t want to deal with the copyleft
  • open core – similar, but also not include certain features into the FOSS version
  • SaaS – can be run as either dual-license or open core
  • delayed FOSS release – the software is proprietary by default, but gets (automatically) released as FOSS after a certain time
  • sell something else (hardware, services, 
) and just have FOSS help sell it, by building a striving ecosystem around it
  • sponsored development & bounties – keep everything FOSS, but have customers pay you for adding more complex features

The alternative is, of course, to rely on donations and/or grants from organisations such as NLnet, Sovereign Tech Fund, Linux Foundation etc.

In Europe there is currently also in the works a European Digital Infrastructure Consortium (EDIC), where many EU countries are joining in to form a common consortium to fund development and maintenance of critical IT (FOSS!) infrastructure.

Specific problem

This leads us to the specific problem to MongoDB, Elastic, Redis &co.

On face-value what is common to all of these adopters of SSPL (and Commons Clause before it) are that they are all database back-ends as such, unfortunately, no existing FOSS license has a copyleft clause strong enough to apply to back-end software. As SSPL – as the best, yet very flawed, stab at it so far – shows, it’s not easy to make it work.

But that does beg the question why that would be needed, if Linux, Postgres, Apache etc. are fine, while the above are not 


The typical “free-to-fee” conversion rate (e.g. FOSS users : paid customers) for FOSS businesses is said to be about 1-5%. Which may be much lower than what some might expect.

And here is where we come to another commonality of MongoDB, Elastic, Redis etc. – all of these changed their license from FOSS to source-available around the time they were either involved with VC (demand to return on their) investment or going public (IPO). Which means that their business suddenly was led (through money) in a way that demanded a quick return of investment.

Let’s say customers = conversion_rate × community_members – in such a situation you have two options to make the customers number go up:

  • either grow the number of community_members – takes a long time, but is ultimately more sustainable
  • or force the conversion_rate to skyrocket – fast, but also breaks established relationships and trust

If you look at conversion_rate=0.05 as something you can live with and want to engage with the community, to help grow together, then you’ll decide to take it slow and grow your community. (This is how these companies worked before VC/IPO)

But if you see 1-5% conversion rate as “plenty of room for improvement” and realise that if you closed the source and through that force, let’s say 30% of community_members to convert to customers, taking into account you might completely lose, let’s say, 50% of the community members, that’s a huge win. (This is how it was after VC/IPO)

Short-sighted? Yes. Profitable right now? Also yes.


 and back to Redis and its forks

Again, I don’t know enough about Redis to judge, but I found this an interesting read:

https://andrewkelley.me/post/redis-renamed-to-redict.html

1 Like