The old maxim that the nice thing about standards is that there are so many to choose from could well apply to open source licensing. While now nearing a couple years old, the last WhiteSource Software survey of the top 10 open source licenses found close competition between the GPL, MIT, and Apache licenses. While the commercial-friendly Apache license has dominated the world of big data platforms and AI frameworks, MIT and GPL (which has "copyleft" provisions requiring developers to contribute back all modifications and enhancements) continues to be popular. GPL and variants such as the AGPL have been popular amongst vendors that seek to control their own open source projects, like MongoDB.
The challenge when licenses proliferate is that it can add legal overhead, especially when a new license comes in and community members must absorb the changes that will impact how they develop, make money, while remaining true to the open source spirit. Who wants to have to bring in more lawyers?
The open source license de jour has disproportionate impact on startup vendors. As we noted, back in one of our first ZDnet posts a couple years ago, "in emerging technology markets -- open source is increasingly the rule, not the exception."
So, what to make of MongoDB's announcement today that it is creating a new license based, not on the AGPL license that it has been using, but the GNU-GPL 3.0 license? Here's an excerpt of the license AGPL clause that is impacted:
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work.
The SSPL changes this by making specific mention of cloud-based service providers, with an excerpt of the modified clause reading as follows:
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
Clearly, the change is directed at cloud platform providers who package their own managed offerings of MongoDB as a service. That means you, IBM Cloud, Scalegrid, and ObjectRocket. But no, we're not talking about you, mLab, because MongoDB has publicly announced its intention to buy the company.
So how does MongoDB avoid coming out looking like the bad guy?
Turn the clock back a couple months when Redis Labs announced it was changing the license. Admittedly, this was not to the core Redis database (which stays under a BSD license), but the surrounding open source modules to a new Commons Clause. These are the modules that let you handle tasks like full text search, accommodate JSON data types, or form SQL-like queries. To recap, this piece in a developer journal was one of the more comprehensive.
Redis Labs made the case that "today's cloud providers have repeatedly violated this ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings." Compared to SSPL, the Commons Clause is more severe, as excerpted below:
"...the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software."
Bottom line? While SSPL requires third parties to contribute changes, the Commons Clause prohibits them from selling them, period. Ouch.
For context, Redis Labs faces a far more existential threat. While MongoDB has cloud rivals offering its database as a service, none of them are the big three. That's right, Amazon, Microsoft Azure, and Google Cloud each delivers their own managed Redis database cloud service. As the Commons Clause doesn't affect the Redis database, these cloud services are not about to go out of business. In TechRepublic, Matt Asay characterized the move as a huge mistake. Barely a week ago, our own Steven J. Vaugh-Nichols reported that developers are now engaging in their own workarounds, taking pre-Commons Clause Redis Modules code and developing them as a separate fork.
As evidenced by its stock price, which has nearly doubled over the past year, MongoDB has not been under any mortal threat. So how does MongoDB avoid the negative press? For starters, it is looking to submit this to Open Source Initiative with the goal of getting community approval as a standard license. The cynical view is that MongoDB wants to tighten the screws as it further ramps up its Atlas managed cloud service, bolstered with the acquisition of one of the largest third parties out there, mLabs.
We have a couple reservations about the new change. The first is that, to keep things simple, we would have preferred that MongoDB made the change to its existing AGPL license, rather than muddying the waters by going with GPL v3. But MongoDB makes a good case that the existing AGPL license ended up proving a bit too confusing (too bad they didn't catch that the first time). Just try cutting through the following clause:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Our second reservation is more serious. Under the SSPL, third parties that offer MongoDB as a service cannot follow an open core model and innovate or add value around it. Under the terms, they must make any associated non-database software available freely. That includes "without limitation management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software."
This change reflects MongoDB's concern that it is facing an uneven playing field, as some public cloud providers won't make APIs to such associated offerings, such as identity and access management, available to MongoDB. So MongoDB is not exactly feeling magnanimous here. We would have preferred that MongoDB instead required commercial arrangements such as a royalty that would allow open core competitors while still giving MongoDB some return.
So, the good news is that unlike Redis Labs' Commons Clause, MongoDB competitors can still stay in business, but they won't be able to add any value without giving it all away or open sourcing it. We don't expect the community to welcome SSPL with open arms. But we do expect that the lawyers are going to get a lot busier.