As a member of the PostgreSQL open-source community, I have been following the recent license change by Redis Labes on March 20, 2024. Redis introduced a dual license model, specifically adding the Redis Source Available License (RSAL), which prevents other vendors from providing Redis as a service without a paid subscription from Redis Labs. The secondary open-source license still allows the source code to be used and modified for non-commercial. While that sounds promising, it mostly just causes further confusion.

This license change has sparked a lot of controversy and criticism from the open-source community. Many users and developers feel betrayed and disappointed by the move, which they see as a violation of the open-source spirit and values. Open-source projects are supposed to be freely available to everyone and the code can be used for any purpose with the correct attribution. Ideally, improvements to the core code base should be contributed back to the main project to keep it healthy but that’s not a requirement.

The problem over the last 15 years or so is that many applications that started as open-source were adopted by large cloud providers to enhance their services, sometimes with a private fork, without providing any help or support to the initial project. Therefore, many of the software creators built companies around the success of their work (Redis in this case, but Mongo and Elasticsearch are other recent examples). But in almost every case, these creator-founded companies simply can’t compete with the size and reach of the major providers and so new licenses are created that try to serve the original open-source users while protecting the viability of the company that supports the development of the software. It’s a hard business.

So why, particularly as a PostgreSQL user and community member, do I care about this?

Well, I believe that PostgreSQL has been an outlier, and shining example, of what can happen when the software is truly developed, “owned”, and supported by the community. With a very permissive license, the past 10 years has helped Postgres grow exponentially faster than if there was an alternative, self-protective license. I think one of the main reasons for this growth and support comes from the issues that Redis and others are often most frustrated with (money aside).

If you join the PostgreSQL community Slack channel, you’ll quickly see that many of the community questions refer to offerings from AWS, Microsoft, and Google. Sometimes the core contributors and long-time community supporters can get pretty frustrated that they have to keep trying to solve problems for features that are not a part of the core Postgres software… features added as part of a DBaaS offering. But as Postgres usage continues to grow, more cloud-specific questions are asked.

Amid this tension, the providers also realized that they could help everyone involved by providing tangible support to the project. Most of this help has come over the last 5-6 years by creating special developer groups which are solely dedicated to contributing to the open-source PostgreSQL project. The developers don’t have any special influence in which features get developed or supported by the community for inclusion in future releases, but they do provide invaluable experience and coding support for the most advanced open-source database in the world.

I wonder if projects like Redis could learn something from this example? What about future open-source projects that might prepare differently as uptake and popularity grows?

Whether the developers of an application are paid for their work or not, nothing about the project is free. If you only take from the project, don’t be surprised when it backfires on you later. But who knows, if you can support the project in some way, “paying” with your time or skill, the future could look a lot different.

What do you think?