Redis Ltd. just merged a Pull Request into the Redis repository, adjusting the license from BSD 3-clause to their own RSALv2+SSPLv1 (Redis Source Available 2.0 + Server-Side Public License 1.0) dual license.
Here’s the commit with the license change:
Here’s the official blogpost regarding the license adjustment, including an FAQ on what changes for whom:
One of the most interesting points in this entire ordeal:
First, we openly acknowledge that this change means Redis is no longer open source under the OSI definition.
This is stemming from the license terms that prohibit redistribution of modified copies of the source code.
Additionally, while they still accept open source contributions on GitHub, these will only be accepted when the contributor signs their CLA now.
There is no News category in the forum yet, once there is, maybe this post should be moved there.
I was just about to post a question, asking for people’s thoughts on CLAs in light of this announcement.
Might as well do it here.
In my view, there is nothing surprising here, although it is still deflating to see another “open source” company drop the fig leaf and go ahead and try to get a bigger share of the pie.
CLAs are what let this happen - I don’t know what percentage of redis is written by people who were not under contract, but you cannot just flip the license on your code without a CLA in place.
That’s why when a project asks for a CLA, they probably already dual license (so they can distribute contributions under a closed license) or they plan to.
I guess there is a somewhat credible argument from Redis that cloud providers are eating their lunch, but they choose to make up for it by first turning away from the OSS community. There is a lot of significance in this.
Back to the topic of CLAs:
IANAL, but I don’t think CLAs are necessary unless you plan, at some point, to dual license or close the source. I think (again, NAL) it is enough to have a disclaimer that anyone that wants to contribute, is assumed to own their contribution (so, for example, your patch is not owned by your company). That way, as long as your project remains GPL/Apache/MIT/whatever, no one will ever bother you.
But you can no longer close it. Because then you violate the license of your community’s contributions.
WFS has a note warning contributors about CLAs in the main content here:
CLAs are a promise of a future rug-pull. And it’s messed up. In the words of Bryan Cantrill, it’s “pissing in the pool of open source”, and I agree.
The idea that cloud providers are eating their lunch is particularly obscene, because it assumes that RedisLabs is somehow more entitled to that lunch than anyone else, and that’s not how free software works. Redis does not belong to them. It is the work of thousands of contributors, most of whom are unrelated to RedisLabs, which is being stolen by RedisLabs and passed off as entirely their own.
Anyway, I depend on Redis so I’m doing some of the groundwork towards establishing a fork.
CLAs are not automatically good or bad: it depends on what the CLA says.
For example, a CLA can allow the original author to switch license between a specific set of licenses that are all listed in the CLA.
E.g. “this software is currently under GPL-3.0-only and could be switched to GPL-3.0-or-later at any time at $author_name’s discretion”. Something like this could be useful in some cases.
I don’t think this is worth it. Again, this comes from a presumption that the original author should have any more rights than anyone else, which I think strongly defies the spirit of, and even to some extent the letter of, free software.
And Element wonder why I don’t trust them when they are saying: “Well, we have no intention of changing the license.” You just changed the license and added requirement for CLA! Who are you kidding? What was your motivation for requiring CLAs then?
It makes me sad that the most famous NoSQL databases are taking such a route.
Is there any data on how effective these actions are for their bottom-line? I’m wondering about the validity of the incentives they are after.
GPL-3.0-only is the problem. Take a look at the Linux kernel, and how GPL-2.0-only caused problems when trying to combine the kernel with other things.
I never use GPL-3.0-or-later and no one else should either. I don’t think the tivoization hole was that big of a deal and I don’t trust the FSF with the indefinite write to relicense my projects.
Because that’s not how it works, you can’t retroactively revoke the old license. Imagine Linux was GPL-3.0-or-later and as of today the FSF released GPL 4.0 as a permissive license. Suddenly Linux as it is today is no longer protected by copyleft, future contributions can be made under GPL-3.0-only but the whole project’s copyleft is lost at the time of the change.
I undestand your concern there, but I just don’t think it’s much of an issue, meanwhile having the “later” results in positive things too. (for example, GPLv3 added clauses for patents and p2p distribution)
