MongoDB’s efforts to get OSI endorsement a more business-friendly SSPL have failed. MongoDB is proceeding anyhow, reflecting a possibly pivotal moment.
After all the drama around MongoDB’s change of license from the open source Affero General Public License (AGPL) to the hopefully-but-not-yet-open-source Server Side Public License (SSPL), the company has now decided to retire the effort. No, MongoDB is not going back to AGPL. Yes, it is sticking with the SSPL. But it no longer is seeking the Open Source Initiative’s blessing to accept SSPL as an open source license.
This decision could show that traditionalist views on open source don’t matter so much today.
The reason MongoDB moved to SSPL
We’re living in interesting times. Never has open source been more pervasive in software, and yet never has it been as much flux as it appears to be now. With cloud giants like Amazon Web Services allegedly able to crush the vendors behind open source projects like MongoDB and Elasticsearch, those same vendors have looked for ways to fend off the cloud giants while encouraging enterprise customers to pay up.
Judging by their earnings reports, the AWS threat has so far seemed more anticipated than actual, but it’s understandable that MongoDB et al. would be looking for ways to protect their investments in code. In a conversation with MongoDB CTO Eliot Horowitz recently, he mentioned that MongoDB has spent more than $300 million to develop the popular database, which it has open-sourced for all to use, free of charge. For AWS or another cloud vendor to take this code without giving something of reasonable value in return is wrong.
Thus the use of SSPL, which basically says, “If you make MongoDB available as a service, you need to contribute back the code that goes into that service.” It’s probably overreaching but, again, it’s not hard to understand why MongoDB is doing it.
Nor is it hard to understand why MongoDB just decided to give up on getting the Open Source Initiative’s blessing on the SSPL.
MongoDB’s new SSPL strategy
The outcry against the SSPL by some in the open source community (including me) was sharp and sustained. Despite good-faith efforts by MongoDB to amend the SSPL to meet objections, ultimately the company opted against continuing to push that boulder uphill, as Horowitz has noted:
We continue to believe that the SSPL complies with the Open Source Definition and the four essential software freedoms. However, based on its reception by the members of this list and the greater open source community, the community consensus required to support OSI approval does not currently appear to exist regarding the copyleft provision of SSPL. Thus, in order to be respectful of the time and efforts of the OSI board and this list’s members, we are hereby withdrawing the SSPL from OSI consideration.
Horowitz detailed plans to further refine the license and to work with others in the industry to try to settle on a response to the looming cloud threat. In the interim, the company will continue to license its Community Edition under the SSPL as if it were open source, allowing users “to review, modify, and distribute the software or redistribute modifications to the software in compliance with the license.” It’s not open source per se, but it does allow open source freedom for most users of the software.
Which is where things get interesting.
Redefining “open source”
While MongoDB has been locked out of open source Linux distributions (like Red Hat’s Enterprise Linux and Fedora), it’s by no means certain that the database leader will suffer as a result. MongoDB used to rank fourth on the DB-Engines database popularity ranking, but has fallen behind PostgreSQL (even as it climbs against Oracle, MySQL, and Microsoft’s SQL Server). At the same time, its corporate revenues have continued to balloon.
The hype “bloom” may be off the MongoDB “rose,” as it were, but it has never been more relevant. Indeed, the fact that AWS chose to build a database service with API compatibility to older, non-SSPL-licensed versions of MongoDB is a clear indicator of just how important MongoDB is.
Will the move to SSPL change that? Maybe, maybe not. Vanishingly few developers make source code-level changes to MongoDB. It’s almost certain that most developers who embrace the database care much more about getting free access to use it (for test and development) than which particular license that governs it.
After all, these same developers that hang out on GitHub increasingly seem oblivious to licenses at all. For years, as much as 85 percent of GitHub repositories didn’t carry a license at all, open source or otherwise. Despite GitHub’s efforts to educate developers on the importance of licensing, it remains true that the majority of GitHub repositories can’t be bothered with licensing. For this crowd, access to the code is the primary concern, not how it’s licensed.
Is it likely that this post-open-source generation is going to get fussed about whether MongoDB is licensed under AGPL vs. SSPL? Probably not.
One can argue (and I do argue) that this is a big miss—the Open Source Definition does matter, and that OSI’s approval of a license matters, too. But arguments about what developers shouldcare about may not matter very much.
In this way, MongoDB may sport a proprietary license that is “open source” enough for developers. As with developers’ embrace of AWS and other convenient but closed services, “open” may be in the eye of the beholder/developer.
This article originally appeared on InfoWorld.