Developers: Stop Donating Your Work to Cloud Service Providers!
Tags: opensource, saas, cloud, licensing
Published: 2024-03-28 06:11:58

On March 20, Redis [announced](https://redis.com/blog/redis-adopts-dual-source-available-licensing/) its transition from three-clause BSD to a dual-licensed structure with the Redis Source Available License and the Server Side Public License (SSPL), resulting immediately in much consternation among the open-source community, as evidenced on the [GitHub pull request](https://github.com/redis/redis/pull/13157) making this change as well as on [Hacker News](https://news.ycombinator.com/item?id=39772562), [Reddit](https://www.reddit.com/r/programming/comments/1bjz7z7/redis_adopts_dual_sourceavailable_licensing/), and other platforms where the community congregates. By now it’s well-known that software released under the SSPL is not considered open source by the Open Source Initiative (OSI), because the license [violates criterion 6](https://opensource.org/blog/the-sspl-is-not-an-open-source-license) of the Open Source Definition by discriminating against those making the software available as a service.

This is the latest in a long line of open-source companies moving to a more restrictive license — [Terraform](https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license) was moved from the Mozilla Public License to the Business Source License last year, [Elasticsearch](https://www.elastic.co/blog/elastic-license-update) switched from Apache 2.0 to the SSPL in 2021, and [Grafana](https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relicensing-to-agplv3/) changed from Apache 2.0 to the GNU Affero General Public License (AGPL) later that year, just to list a few. Each of these instances caused at least some backlash in the community, with developers decrying them as restricting their freedoms and (except for the AGPL, which somehow achieved OSI approval) moving away from open source.

Have all these companies used the open-source community simply as a way of promoting their products, with the intention from day one to pull the rug out from under the community and steal their work? Or have they sold their souls for sweet venture capital and been corrupted by MBAs lurking in their leadership? This is often the prevailing sentiment in online discussion.

## The Newest Threat to Open Source

The truth is that in the war for software freedom, the battlefield has shifted. While many developers continue to focus on the traditional enemy of proprietary software, a greater foe has emerged in the form of cloud service providers. Instead of openly demonizing free software like the Microsofts of the 1990s, their attack on free software is much more insidious. **They don’t want to kill open source; they want it to grow.** They sponsor all the conventions and initiatives and foundations, proudly proclaiming their support for free software, and even assigning developers to work full-time on open-source projects. They are happy to make these investments in open-source software because they know that **they will be the only ones to profit from it.**

The developer community may still be on the fence about this, but for open-source companies like mine, the age of innocence is over. In their [relicensing announcement](https://www.timescale.com/blog/how-we-are-building-a-self-sustaining-open-source-business-in-the-cloud-era/), Timescale referred to the new crop of SSPL alternates as “cloud protection licenses”, making the point quite clear. In the cloud-driven world of today, **selling enterprise services for open-source software is no longer a sustainable business model** when your entire product can be sold as a service by massive corporations. Building a better product and stronger community is no longer a recipe for success when cloud service providers are free to package and sell your product, contribute little more than lip service, and encourage your community to push back against any action you take to benefit from the success of your own work. Independent developers may question the motives of for-profit companies, but my open-source time-series database project [TDengine](https://tdengine.com) now pays the salaries of over 50 developers, all of whom contribute to our [codebase on GitHub](https://github.com/taosdata/TDengine). It would be impossible to support this development team financially if we had to compete against the cloud providers to sell our own product.

Some developers claim that software freedom demands cloud service providers enjoy the same rights as individual developers, similar to those who insist that it is unfair for billionaires to pay higher taxes. They believe that restricting cloud service providers from exploiting your work goes against the spirit of open source as defined by the OSI, whose programs, according to their website, are “supported by Amazon, Google Open Source, and people like you.” (In what appears to be an oversight, Microsoft did not spend enough to be featured on the homepage.) And cloud service providers are delighted to have these principled absolutists on their side. **Every line of MIT or BSD code that they write is a free contribution to the SaaS products of tomorrow.**

If you are dedicated to working for massive corporations for free, don’t worry — cloud service providers are always quick to support the community in creating a fork. It happened with OpenSearch in 2021 and is happening with Redis forks as we speak — though it is surely just a coincidence that an AWS employee is driving the effort. Your ability to put more power in the hands of a few large companies cannot be hindered by license changes and will assuredly result in a better software landscape for the robber barons who exercise their freedom to use your code.

## One Step Backward, Two Steps Forward

When I first turned my attention to free software in the early 2000s, the GNU General Public License (GPL) was the most popular licensing choice for open-source projects, and I distinctly remember the constant hand-wringing about licensing issues preventing the introduction of code into GPL repositories. For developers, moving toward permissive licenses was a natural reaction — we wanted to make our code available to everyone and we wanted everyone’s code to be available to us. We wanted to build and support a community based on mutual contribution and benefit, not get bogged down in the murky legal details and pointless ideological battles associated with copyleft.

The consequences of that shift are only now becoming apparent. In our quest for freedom, we empowered those in a position to exploit us. For the sake of convenience, we put individual developers and small businesses at the mercy of large corporations and consolidated power in the oligarchy of the public cloud. Now it is time for all of us in the open-source community to realize that **releasing projects under permissive licenses is in essence a donation of our time and effort to the cloud service providers** who will snap them up and sell them back to us.

In 2019 when I open-sourced my distributed time-series database TDengine, I chose the AGPL specifically to stay true to open-source principles while preventing unilateral monetization by cloud service providers. The AGPL is not perfect, nor are attempts to improve on it like the SSPL, but I am confident that it is the best choice for the present and equally confident that the greater community, once the severity of the current situation is realized, will come together again and create even better licensing options for future open-source projects. For now, I call on open-source companies and developers alike to open their eyes and stop donating your work to cloud service providers. Protect your rights by using copyleft licensing for any serious projects. If someone gets paid for your work, it should be you.