It’s never been simple to be an Open Source vendor. With the rise of the cloud and the emergence of software as a service, the open source monetization model continues to encounter risks and challenges. A recent example can be found in MongoDB, the most prevalent NoSQL OSS vendor, which just changed its license from AGPL license to a new, more-restrictive license called SSPL.
This article will cover why MongoDB made this change, and the problems and risks of the new model. We’ll show how SSPL broadens the definition of copyleft to an almost impossible extent and argue that MongoDB would have been better off with Commons Clause or just swallowed a hard pill and stayed with APGL.
Why a new license?
According to a recent post by MongoDB’s CTO, Elliot Horowitz, MongoDB suffers from unfair usage of their software by vendors who resell it as a service.
Elliot claims the AGPL clause that is supposed to protect the software from being abused in such a manner isn’t enough, since enforcing it would result in costly legal expenses.
As an OSS co-founder myself, these claims seem valid at first blush. Shouldn’t vendors and communities defend themselves against organizations that just consume technology without contributing anything back? How can an OSS vendor maintain a sustainable business and how can it grow?
As InfluxDB CTO Paul Dix said, someone needs to subsidize OSS, otherwise it cannot exist. There are cases where it’s being subsidized by a consortium of companies or foundations (Linux, Apache). There are cases where very profitable corporations (Google/Facebook), who rely on their profits from other business models, act as “patrons-of-the-arts” to open source code for various reasons — for instance, to attract top talent, to be considered a benevolent brand, or attract a large user base for their other proprietary products.
Pure OSS vendors are under constant pressure since their business model needs to subsidize their development and their margins are tight. Indeed, many OSS vendors are forced to an open core approach while they hold back functionality from the community (Cloudera), provide some of the closed-source functionality as a service (Databricks) or even making a complete U-turn, back to closed-source software (DataStax).
Could MongoDB and RedisLabs (who recently changed to Apache 2 + Commons Clause licensing; the core remained BSD) have found the perfect solution? These new solutions allow them to keep sharing the code while having an edge over opportunistic commercializers who take advantage of OSS with little to no contributions.
APGL vs. SSPL: A side-by-side comparison
For specifics, do a side-by-side comparison. Specifically, look at APGL’s section 13, where “Remote Network Interaction” was totally replaced by SSPL’s limitations around “Offering the Program as a Service,” with completely new text therein.
SSPL requires that if you offer software as a service you must make public, open source, practically almost everything related to your service:
“including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.”
What’s the risk of SSPL?
From a 30,000 foot view, it might sound fair. Community users will be able to read the software, and use it for internal purposes, while usage that directly competes with the OSS vendor’s service model will be disallowed. Have your A
APGL vs. SSPL: A side-by-side comparison
cake and eat it, too!
Hmmm… not so fast. Life, software and law aren’t so simple.
On the surface, the intention is good and clear, the following two types of OSS usage will be handled fairly well:
- Valid OSS internal usage
A company, let’s call it CatWalkingStartup, uses MongoDB OSS to store cat walking paths. It’s definitely not a MongoDB competitor and not a database service, thus a valid use of the license. - MongoDB as a service usage
A company, let’s call it BetterBiggerCloud, offers MongoDB as a service without contributing back a single line of code. This is not a valid use according to SSPL. In such a case, BetterBiggerCloud will either need to pay for an Enterprise license or open all of their code base (which is less likely to happen).
Here’s where things get complicated. Let’s imagine the usage of a hypothetical company like a Twilio or a PubNub (these are just presented for example, this is not to assert whether they do or ever have used MongoDB). Imagine they use MongoDB and provide APIs on top of their core service. Would this be considered a fair usage? They do provide a service and make money by using database APIs and offering additional/different APIs on top of it. At what point is the implementation far enough from the original?
GPL and the Linux kernel used a cleaner definition where usage is defined as derived work. Thus, linking with the Linux kernel is considered derived and userspace programs are independent. There is a small gray area with applications that share memory between userspace and kernel, but, for the most part, the definition of what is allowed is well understood.
With the goal of closing the loophole with services, AGPL defined the term ‘Remote Network Interactions.’ The problem with SSPL is that there are only barely such boundaries. And now – users must share their backup code, monitoring code and everything else. It doesn’t seem practical and is very hard to defend on non trivial cases.
I wonder if folks at MongoDB have given this enough thought. What if a cloud service does not use the MongoDB query language and instead offers a slightly different interface to query and save JSON objects? Would it be allowed?
Should others follow SSPL?
In a word, no.
If you did intend to sell MongoDB as a service, you have to open source your whole store. It may be acceptable to smaller players but you wouldn’t find large businesses that will agree to this. It might as well just read, “You are not allowed to offer MongoDB as a service.”
MongoDB is foolishly overreaching.
The intent to control others offering MongoDB-as-a-[commercialized]-service is commendable. To desire to profit off your work when it is commercialized by others seems all well-and-good and Commons Clause takes care of it (although it expands beyond the limits of services). But let’s face it, there is nothing that unique about services; it’s more about commercializing the $300M investment in MongoDB.
I actually do not think this is MongoDB trying to turn itself into a “second Oracle.” I believe the intentions of MongoDB’s technical team are honest. However, they may have missed a loophole with their SSPL and generated more problems than solutions. It would have been better to use the existing OSS/Enterprise toolset instead of creating confusion. The motivation, to keep as much code as possible open, is admirable and positive.
This is, of course, not the end of open source software vendors. Quite the contrary. The OSS movement keeps on growing. There are more OSS vendors, one of whom just recently IPOed (Elasticsearch) and others on their way towards IPO.
While Open Source is not going away, the business models around it must and will continue to evolve. SSPL was a stab at correcting a widely-perceived deficiency by MongoDB. However, we believe there are better, less-burdensome ways to address the issue.
Disclosure: ScyllaDB is a reimplementation of Apache Cassandra in C++. ScyllaDB chose AGPL for its database product for the very same reasons MongoDB originally chose AGPL. Our core engine, Seastar, is licensed under Apache 2.0
Editor’s Note: This article has been updated to clarify Redis Labs license model. (October 29, 2018)
