Why Now? And Who? The Struggle Over Single-Vendor / Open-Core Licensing

Update 2023-08-26: Redis writes to us that they rebranded from Redis Labs, to Redis.

---

In yesterday’s talk I reviewed the current licensing struggle of single-vendor open source firms. Single-vendor open source firms go to market by providing software they developed for free, under an open source license, while also offering a commercially licensed version of this software, possibly with extensions and services that customers may want to pay for. Because of the open source version of this software, large cloud vendors can compete with the original vendor for running this software as a service. They did this so well that some single-vendor firms decided to change their future licensing to a proprietary license to stall the competition, irking the open source community and creating a backlash on many sides.

This business model has been in the making for over 25 years, so the questions arises: Why now? I thought the answer was that only now the large public cloud providers got ready to compete. But in the run-up to yesterday’s talk, in a discussion with Michael Herzog of NexB, I realized that this is only one part of the answer. The other part is hidden in the specific type of single-vendor / open-core software.

Here is how I summarize the history of this business model:

• The pioneers. The early companies invented the model in the nineties and defined it as they went about their business. Example companies are MySQL, Sleepycat Software, and Trolltech.
• The second generation. In the twothousands, motivated by the earlier successes, venture capitalists and entrepreneurs tried to cookie-cut the model and disrupt existing enterprise software markets. Example companies are SugarCRM, Jaspersoft, and MuleSoft.
• The current wave. Following on the heels of the success of the second generation, this business approach became popular. Of note are MongoDB, Redis Labs, and Confluent, because they changed their licenses for the reasons laid out earlier.

The prominent companies from the second wave that I intuitively listed provided turnkey solutions for business customers. Initial buyers were often lines-of-business, not the IT department. My examples for the current breed are all tech companies that provide components for developers who then built their applications using this software. These users are more sensitive to licensing and also more savvy.

In yesterday’s talk I laid out how the intellectual property strategy of single-vendor open source firms works. The key practices are:

1. Own all core IP (and never let go) if you can
2. Use the most aggressive license (AGPLv3) all the way
3. Accept outside contributions only if they sign over their copyright

Practice 2 explains the problem. Pure single-vendor turn-key enterprise open source can use the AGPLv3 license all the way, making it unattractive for companies to compete with the original vendor (because they would have to open source all code that touches the AGPLv3-licensed code). Single-vendor application component open source vendors would stall the adoption of their software if they applied the AGPLv3 license all the way. So they didn’t, but rather shielded users from an aggressively licensed core through a less aggressively licensed shim (or used permissive licenses right way). This way, they drove adoption among application developers, but also opened the door for competition. C’est la vie.

This is not an unheard of problem. If memory serves me right, MySQL’s client library originally was LGPLv2, decoupling user applications from the GPLv2-licensed database core. Sales only took off, however, when the client library got relicensed to GPLv2, forcing the hand of developers using MySQL. Maybe this is also the better solution for today’s breed. Don’t abandon the open source license for a proprietary one, but stay with an aggressive open source license all the way, even if it slows adoption.

So then, we can conclude with a somewhat positive perspective: Not all software has the competition-from-cloud-providers problem, only companies who want to drive adoption through less aggressively licensed shims. Then, the AGPLv3 has not lost its bite, as I wondered. And finally, if vendors are transparent about potential future license changes, they may be able to stay within the open source framework.

Next up: Free-to-Use, Unless You Are a Cloud Provider (The New Strategy?)