License Changes Concerning Redis, An Optional Dependency For Swish

Discussion
,
1

For those interested in libre and foss licenses,
I should point out some significant changes to Redis’ policy.

This could be of pertinence to SWISH developers and users.

Context

Beginning today, all future versions of Redis will be released with source-available licenses. Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1). Consequently, Redis will no longer be distributed under the three-clause Berkeley Software Distribution (BSD).

h/t Change license from BSD-3 to dual RSALv2+SSPLv1 by K-Jo · Pull Request #13157 · redis/redis · GitHub

Forks

There are already forks.

This one including one which asserts an LGPL licence.
It involves the person behind Sourceforge (among other things).

h/t Codeberg.org: „We are proud to be home to #Redict, the #fork of …“ - social.anoxinon.de - Mastodon

Here is another fork (same BSD license), though I wont comment on the provenance:

h/t Change license from BSD-3 to dual RSALv2+SSPLv1 by K-Jo · Pull Request #13157 · redis/redis · GitHub

Swish

While there are numerous references to Redis in the Repo, I thought Id reference these documentation links:

1 Like
2

Thanks for the info. Looks like we’ll continue to see some form of Redis that is free.

The sad bottom line is that it is hard to make a business from completely free software and thus many producers of free software consider a dual license scheme with a basic free version and a paid version with additional features. I thought that notably database vendors could escape from that because managing a distributed database installation with high availability and backups is typically far from trivial and thus companies may opt for SaaS solution.

This is a pity as in the end everyone suffers. The producers face all the complications of maintaining two versions, managing licenses and payments. The users are faced with more complicated installation (not in e.g., Linux packages, download access behind a paywall, etc.) and/or an artificially crippled version.

3

I think its merely an impedance that Redis’ parent behaved this way.

Ultimately, I consider it a faux pas which will undermine their longterm interests.
The outcome is that like OpenOffice being superseeded by LibreOffice that there will be a sufficent confluence of organisations and community groups which will want to assert more libresoft behaviour.

For example, the mentioned Redict fork has upgraded licensing accountability:

There are kite flying exercises regarding which aspects of the original Redis stack should be upgraded.

For example, here is a stub regarding updating Redict’s usage of Lua away from Lua 5.1:

As such, a fragmentation of Redis’ community may allow for breaking changes that would be impossible (or at great cost) to implement.

Given this, it may be worth considering any aspects regarding how Redis would be more apt for SWISH’s criteria and submitting it as an issue.

1 Like
4

Thanks for the REUSE pointer. Could be a good idea. As is, problems with licenses are often detected by (notably) the Debian maintainers. If we can make their live easier, so much the better :slight_smile:

I agree that all this dual licensing is a nightmare. I already pointed out a few issues, but you correctly point out more such as fragmenting the community. The reasons why companies go for dual licenses are probably diverse.

If you or others have experience with financing open source projects and ideas how this could apply to SWI-Prolog, please contact me. I’m keen to discuss them. Dual licensing is pretty much at the bottom of my list of preferences :slight_smile:

5

… well for what its worth I am in the final round for NLNet funding
(Ive previously overseen the Gemini protocol and kanban board project, Icebreaker).
Ill be sending my submission on Monday.

The gist of the project is to fuse both a RDF transport agent for Fediverse content and VOIP functionality onto SWISH.
I consider the use of Biomake and Swish to be an exemplary approach to harmonising both local and remote operating environments (my specialism is regarding knowledge-management but my focus is often directed towards interpreting and modelling content and content flows).

Id prefer not to confuse this thread and prefer to operate bilaterally for the time being on this FOSS initiative.
If you are interested, I shall send you a WIP draft early Sunday to the email address found here:
https://www.swi-prolog.com/contact.html

6

“Today, the Linux Foundation announced its intent to form Valkey, an open source alternative to the Redis in-memory, NoSQL data store.”

1 Like
8

Luckily it is a fork, so it seems we can keep using the Prolog Redis library. Now we must hope that the network protocol of the two stays compatible …