MongoDB's Server Side Public License Is Likely Unenforceable
processmechanics.com
processmechanics.com
This bit in particular really hits the nail on the head:
Let's assume that it is ok somehow to pass forward other open source software, solving that problem. What about my continuous integration software (e.g. CircleCI), or my business backup software (e.g. Jungle Disk) or my code hosting service (e.g. Github)? There is no logical bound to this license. Taken on its face, I would theoretically be bound to release the internal source code of services from third parties that I included in or relied upon to deliver my service.
Copyleft is one thing, but this is so invasive and byzantine that it beggars belief that anybody actually thought this license made sense.
1. Big cloud vendors are making money off MongoDB's investment Completely untrue. The big three - AWS, Azure and GCP dont have a MongoDB as a service solution. The only commercial entity making any real money off MongoDB is MongoDB, Inc. AGPL has achieved its purpose here. The only big cloud vendor with a solution is Rackspace and they release their modified MongoDB code.
2. Big cloud Vendors in China are breaking the law and they need this new license to control them If they are technically modifying the source code and not providing it back to the community then they are already breaking the law. You don't need a new license to control this problem
So what is this about? In my opinion it is an exercise in naked extortion and control
1. Clear out any ISV Vendors/As-a-service Competitors - Any commerical entity who does anything remotely interesting with MongoDB is in big trouble. I'm talking about Monitoring, backup, performance profiling, analytics, reporting etc..anything really. MongoDB could easily bring a reasonable claim against them that the value of their service is "primarily or mostly derived from MongoDB". Also its very unclear on what needs to be open sourced to be compatible. The license seems deliberately vaguely worded so that it is as broad as possible.
2. End users using MongoDB - While MongoDB claims this does not affect end users in any way I would be very wary of this claim. The license in authored in such a generic way that there are many possible interpretations. If MongoDB, Inc for some reason does a claim against you then your only defence is to buy a license or go into litigation. "Trust us, we will never do that" is not a good enough argument.
To summarize, be very wary of this. If you are a developer and dont think this affects you run this by your legal deparment or VC and see the alarm on their faces :)
Let say you are a young startup building a cool SaaS solution. E.g. A data analytics solution. If you make heavy use of MongoDB it is very possible that down the line the good folks at MongoDB come calling since "the value of your SaaS derives primarily from MongoDB..." So at that point you have two options - buy a license from MongoDB or open source your work (which they can conveniently leverage at no cost).
Either way if you are SaaS solution doing anything data related I would not use MongoDB having read this license.
It's obvious that several people disagree, but within this thread, conversing about this article, we should expect a bias to see things that way. I hope you'll stay open to being convinced otherwise. The SSPL has been submitted for review to the OSI, and this issue is one of the points of discussion that we're listening very closely to.
If that were true they could switch to Postgres and become 200x as valuable overnight.
It makes complete sense if its purpose is to be so onerous that no one can actually use it without a commercial license.
That’s virtually the word-for-word conclusion that anyone who’s “has some time to look at mongoDB” has come to. It’s a steaming pile of feces, and this is no surprise. From day one, the mongo team has made it clear that they are a startup first (in the sense of “focus on wooing investors with buzzwords and making money”) and a software engineering firm last.
Because of its previous license, the code base can be forked as of immediately before the license change, and it can continue to be offered under the previous license.
I would recommend that anyone using MongoDB do that.
Can you elaborate on this?
GPL steers clear of non-derived work. If you use VMWare on Linux, VMWare is not a derived work as far as copyright law is concerned and there is no relation between them as far as GPL is concerned.
This SSPL, is another story.
The issue is not about having to buy a license here. The problem is the uncertainty with a product whose license agreement is being switched over mid-stream. It makes me weary of what else might happen with their license structure further down the road.
not nit-picking, just attempting to help other readers who aren't native English speakers
On the subject, we pronounce "router" and "router" (two different words, same spelling) differently, one with a diphthong, one without.
I've always heard it pronounced way-ree.
I can fully understand the frustration of pro-copyleft developers and companies that want to use copyleft for a 'share or pay model'. Cloud computing makes existing licenses toothless by moving the software from the client to the server, thereby avoiding distribution. It can be argued that such use is not in the spirit of copyleft and is effectively a loophole from the perspective of copyleft licensing.
It is not surprising that people try to make new copyleft licenses that fill that loophole. This may not be the best formulation, but it is definitely much better than the Commons Clause nonsense that was hyped a couple of weeks ago (which makes software proprietary).
[1] Whether it is enforceable is another issue.
I’m unsympathetic to the “oh no the cloud” mindset. I’ve worked at companies that have made on-premise patches to FOSS since the 90s. Can you imagine if Linux required you to make the source available of all software you ran on it? Or MySQL? Or Perl/PHP? I can vaguely see the point of the AGPL for things like web front end stuff where there’s a blurry line between you visitor merely visiting your site and you distributing the software to them. But that’s just madness for infrastructure code.
And I’ll bet that the MongoDB team has used lots of FOSS that they didn’t financially support, so I see it as whining when they complain about others doing the same.
It's perfectly understandable if you decide not to use their software because you find their license unacceptable but don't insult them for doing what they want with their own project. If a sizeable enough number of contributors are unhappy with the move they're still free to fork and continue the previous version of Mongo DB with the old license.
I think it’s either:
- Idiotic, because they meant well but managed to shoot themselves in the foot by making their software unviable, or
- Malevolent, because they’re using this as a wedge to either force you into a pay-or-lose-it situation, while still trying to paint themselves as FOSS.
You’re free to change your licenses (or not), just as other projects are (but should).
It’s time the free ride and expectations of charity by for-profit users ends.
You say "freeloading". I say "participating in a rich culture of shared work". Maybe I don't contribute all my local work to Emacs upstream, but I push out a lot of Python stuff. Maybe you don't bother sharing all the Python tweaks you've made, but you're an active Vim contributor. Perhaps there's someone else that's a Vim "freeloader" but who cranks out a lot of kernel code that you and I both benefit from. I think that's a healthy, mutually-beneficial arrangement.
It’s clearly not mutually beneficial when one side is reaping outsized rewards (and not at all ashamed about it), and your example of small contributions to vim and python is disingenuous; we’re talking about entire software packages used without compensation by businesses (Redis, Elastic, Mongo to name a few).
If Mongo were a closed, proprietary product who wanted to be paid, sure. I happily pay for Apple stuff, for instance. But saying "hey, come use our FOSS project!" and then pivoting to "...as long as you pay up!" is extremely disingenuous.
This is absolutely no different than commercial vendors who change pricing or licensing terms year to year (ie “we no longer offer an on prem version; SaaS only now; last year you paid $100k, this year our price is $200k”). You’ve just been anchored to an unusually low price previously.
MongoDB is little more than mmap() attached to a socket. They would be nowhere without piggybacking on a million lines of other people’s free code.
> ...
> [1]Whether it is enforceable is another issue.
As per the article, apparently not. Copyright Misuse [1] will stop them setting terms beyond a certain scope. You could argue that that merely makes the licence unenforceable but by that definition the only thing worth talking about is enforceability, so that doesn't seem like a good definition as there are practical enforceability issues to separately consider
> If you dislike the license, then use a different program
That's exactly what he said he would do, isn't it?
RoboMongo,MongoGUI etc... they all received a legal notice to remove the name mongo from their product.
This was probably one of the most evil thing have seen in the open source industry .
Most of those vendors were open source with paid premium features or donation.
After receiving their legal notice most of those vendors deprecated or sold their project to a company feeling betrayed by Mongo.
As a result Mongo Compass became the de facto GUI for MongoDB and is advertise as sold with MongoDB Enterprise.
For example, there's the whole uBlock vs uBlock Origin thing, where uBlock Origin is the good one run by the original maintainer, and uBlock is run by people who had nothing to do with the original project.
https://en.wikipedia.org/wiki/UBlock_Origin
Trademarks can be used offensively, and few cases were more offensive than the Linux trademark dispute back in the 1990s, when William R. Della Croce, Jr., someone with nothing to do with the Linux kernel or anything else of value, acquired the trademark to "Linux" in September 1995 and began to demand royalties from the people who did useful things with their time. It took a court case to dislodge him.
https://en.wikipedia.org/wiki/Linux_Mark_Institute
https://www.linuxjournal.com/article/2559
What Mongo did was meaningfully better than what Della Croce did, and closer to the spirit of "prevent people from confusing products and thinking stuff is from the original development team when it isn't", but I can see how it would be an unpleasant shock in the Open Source world which, sadly, usually doesn't know or do a damned thing about trademarks until some asshole forces the issue.
What you should consider in your rage against trademarks is that they protect something far weaker than copyrights and patents. Trademarks are fundamentally exchangeable identifiers. They do not hold any value beyond what they are infused with due to their attachment to some company (person/organisation/...). Unlike patents, which cordon off the part of scientific reality from most, or copyright, which fundamentally relies on deadweight losses to make its mechanism work, trademarks are almost exclusively positive: there is nothing you gain from calling your product "Mongo-X" apart from the meaning the term carries based on the company creating the product.
(This slightly glosses over some practicalities, such as some terms having meaning before being adopted as a trademark, or the possible depletion of combinations of letters that can be pronounced. But those are just superficial practicalities, and they are acknowledged in various limits to trademarks).
I fully expect them to flame out in the next couple of years.
Of course their sales people are saying "No. We won't use it that way." Sales people gonna sell.
I'm sure the people currently running MongoDB would not do that. What happens when they get acquired by, say, Oracle? Or some other company that absolutely would do that?
The bottom line that you have to assume from a legal point of view is that any part of an agreement that can be abused, will be abused. This not only can be and will be, but it will be really easy.
If they are doing this to prevent people from competing with their own service--which they absolutely are--then they need to rewrite it and make that explicit. This is way too squishy for anyone with an ounce of brains to use in a commercial product.
According to our poll many users will seek alternatives for MongoDB because of the license change
https://www.percona.com/blog/2018/10/24/poll-mongodb-license...
MongoDB probably feels they have reached critical mass so it does not matter any more...
They have become a new standard and they are aware of it.
Just look at any bootcamps for devs this days , it’s basically always JS + MongoDB. Not Postgres or MySQL , Mongo.
Mongo has become the new MySQL for a lot of devs these days.
It’s often the only DBMS they know...
These move is somewhat coherent with what others are doing in the industry ( Redis Enterprise Modules new licence , Docker preventing download without creating an account etc...)
Open Source is now Venture Backed , as a result it needs to make profit.
The online classes love Firebase. :-D
But yeah, I had to explain to a bootcamp dev a few weeks ago what Postgres was. I felt rather sad.
The general risk with any for profit open source company is either them pulling all the good features into the paid version, or suddenly changing your license so that closed source projects have to either stay on the old versions or pay for a commercial license.
The issue here is that SaaS providers are building tools on top of MongoDB that effectively add functionality, instead of modifying MongoDB (which would force them to share those changes publicly).
This is a valid concern and I understand the motivation behind the license change. However, how is this different from any other FOSS?
Just as a random example, think of a proprietary blog/site provider like Tumblr and Weebly. They are effectively a SaaS provider that introduces tools on top of open-source web servers (like nginx or apache) to make hosting a website much easier. Instead of building the entire model/code of your website, you simply add customizations using a frontend.
Maybe the comparison is not ideal, but my understanding is that all FOSS suffers from this concern, and the industry seems to be doing well enough.
You're in the right ballpark, for sure, but the SSPL addresses the difference explicitly. I'll use your example of Tumblr to clarify.
Tumblr is built on some component technologies, like a database, an app framework, operating systems, backup systems, load balancing, etc. But Tumblr itself is not any of those things. Nor does it make any of its component technologies available to the public as a service. You cannot pay Tumblr to backup your servers, or to rent you VMs running an OS, or to do load balancing for your infrastructure. Even if every single one of those components were licensed under the SSPL, Tumblr would not have to release a single line of their code under the SSPL, because they provide something else -- a publishing platform.
I could do the same thing with a worse UI by hosting MongoDB on an open port.
But even if they are right, this doesn't seem smart, it feels like a knee jerk reaction. I imagine that they hope that by doing this they'll cause people who are using mongo on other providers to move to mongolabs, since there is 0 chance of these providers open sourcing their infra.
But that's not whats going to happen, either cloud providers will remain with old versions and people will gradually move to different dbs or they'll just fork it, they certainly have the manpower for it, this will give them incentive.
Frankly though I think this is well within the agpl, cloud providers aren't modifying the code they are building things around it.
Just my opinion, of course, but I think this is only true for sales and management types who are profit driven. For engineers and artists, it's not really an issue. We want to see our best work appreciated, primarily.
I want to be paid first. Everything else comes second. That doesn't not make me an engineer. It makes me a wise engineer. Money buys options and freedom. Prestige and other abstract concepts are used to steal your time and value.
That said, I think MongoDB REALLY screwed up the execution here, even though I can definitely sympathize with what they were aiming to accomplish.
This isn't me trying to argue against the article; I'm trying to understand the law as it applies to my profession.
I doubt it will work since many people will indeed not want to deal with companies that are dangling legal threats over their own users like this. IMHO there's no other way to interpret this than as exactly that: a user hostile move. Whether this thing is enforceable or not is beside the point.
It’s not with licensing shenanigans that they’ll fix a monetization failure; in fact, it will likely backfire. It’s hard enough to push (A)GPL software in enterprise contexts, by making it even more awkward they are basically begging users to go away.
Forcing droves of community users to buy commercial licenses is not the intention of the SSPL -- indeed, it cannot serve that function, as it does not obligate them to do anything at all unless they are making the licensed software itself available to the public as a service.
I'd recommend sticking with well understood OSS licenses. There are plenty of those. This one is neither OSS (until the OSS foundation says otherwise) nor well understood. Both are problems. Especially when mixing with GPLed code. It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license. I'd still argue that that was the main point. I'd suggest celebrating any successful use of your software instead of trying to constrain it.
My suggestion would be to use Apache 2.0 and try to get companies to take a commercial license based on the merit of added value in terms of support, extra goodies, etc. This seems to work well for others in the industry (e.g. Elastic that recently IPOd); it's well understood; explicitly compatible with GPL; and has none of the disadvantage of rolling your own license.
I appreciate your suggestions on what other licensing options we have. I think you really get what we are trying to do. That strategy is exactly how MongoDB has sold its enterprise edition for years. With apologies if I'm pointing you to something you've already read, we think the current landscape of the tech industry makes that insufficient, as our CTO's announcement post goes into: https://www.mongodb.com/blog/post/mongodb-now-released-under...
Anyhow, I do want to address this:
> It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license.
I think this is unfair. Everything we have said about the SSPL makes clear that it has one very exclusive set of targets in mind: large scale cloud providers with the means to strip-mine not just MongoDB, but any open source project with significant traction. And the one actual data point in this conversation supports that position: fatbird posted that they were on a sales call with MongoDB recently, specifically asked if they were affected by the license change, and were told "no". Is that a legally binding rider to the SSPL? Of course, not, but if the plan for the SSPL was to use it to wring money out of community users, wouldn't the answer have been "yes"?
If you've already read that announcement post, or if you now do, would you let me know if it makes anything clearer?
I'm just parroting the sentiments here. This is how this move is perceived.
I think your CTO is wrong on this. This situation is not something that is going to improve with more blog posts, explations, or proclamations from your c level executives.
So, a wise move would be to roll this back ASAP and withdraw the SSPL.
This license is no a solution to Mongo's revenue problems and may actually make things worse. It sure doesn't solve any problems your users are having so whatever this is, it is not in their interest.
Note that the same is true of any property, and terms of sale, rental, or permissive use of other property may be unlawful as anticompetitive or otherwise contrary to public policy; while copyright misuse is a social doctrine evolved from the related doctrine of patent misuse, it's not really all that out of line with the kind of considerations that song with property rights in general.
No, not at all, and this is a key difference between OSS licenses and EULAs. By default "you" (the entity in question, which may be an individual human or legal organization) have the right to use lawfully acquired source code for absolutely anything you wish. What copyright governs is distribution (either of the copyright works or any derivatives, except for exemptions made by Fair Use in places that have such a legal concept). So if I just put source code up for my program and make it freely available and nothing else, then by default you may download that and run it or hack it up or whatever else you want, just as if I gave you a book I wrote you'd be free to mark up the pages or tear some out and reorder it or whatever. You don't need the copyright holder's permission for any use of it.
What you do need permission for is to then share any of that on. So standard open source created a fair and thus very strong quid pro quo essentially: someone is offered additional rights beyond what they'd have by default via a license that requests they do some task in consideration related specifically to that copyrighted work (for some licenses it might only be indemnification from liability and maybe giving credit somewhere, for copyleft it means applying the license to any derivative works as well). There is no click through or "by using this you agree to..." there, your acquisition of the source is entirely separate from a later choice to distribute the source. No license is needed for use, but if you don't agree with the license and don't get another one then you have no right under copyright to distribute [1].
Anyway that's a simplified basis for the theory behind OSS. It's founded in the simple and straightforward application of copyright law and contracts, and it's fundamentally quite fair to all parties and has a very limited and directly related to the work aim. As the article says the further away one tries to get to that the more complex and iffy things can become and the easier it may be to include something that is legally challengeable. Copyright is open source's hammer, but not every aspect of technology is a nail.
----
1: Note that in practice this can at least theoretically get sticky if you're a programmer in a related field (as so many on HN are) rather then a random user, because having read the source code if you then down the road wrote something that looked the same it could be claimed it was derived which is then a huge pain to fight about. For non-high profile areas it's unlikely it'd ever come up, but the future is hard to predict in that area of life so many ethical or just cautious programmers would be careful about looking at source that wasn't open source.
And the recent stink on HN where OSI claimed MongoDB was not Open Source because the license had not yet been reviewed, with many claiming (correctly) that OSI is not the determiner of what is open source, appears to have been out of order.
I think there was a base assumption that the license would in fact be fine, and OSI claiming it wasn't because they hadn't stamped it ... yet ... was overreaching.
Anyway my understanding is that the single largest user (and commercial licensee) of MongoDB hates it and can't wait to get away from it. With that in mind, this licensing nonsense smells like a desperate grab. Maybe it's time to short $MDB?
Am I missing something or is the author? Also, what stance has the 2nd Circuit taken on copyright misuse, if any?
Is there an example of such a license?
Could this type of license even be created in an enforceable way?
Upstream changes made by the project sponsor would be expected to be copyright and released only under the new license.
Unless the copyright holder permitted it (perhaps via the new license), it'd be copyright infringement for anyone to distribute those upstream changes under different terms.
I don't necessarily disagree with the sort of thing they want to do, that definitely fits one kind of business model. But I wouldn't want to go to court the license as presented (and now entered into by some unknown number of people).
Like the LGPL is confusing because it is not written well in some sense. But that goes to "confusing" instead of "unenforceable".
But yes, better written the problem with this license would just be "They are trying to claim things they know they can't claim" instead of "they are actually claiming things they know they can't claim".
The next question that would pop into my head would then be "At what point does attempting to claim rights to things you know you can't, as a way of scaring people into paying you, cross into unfair and deceptive trade practices"
Additional question: if you can fix that problem with the contract with a "to the extent possible" predicate, is that really not the default? Like, if a clause can be interpreted as requiring the impossible, even if a straightforward alternate interpretation doesn't, that clause is broken?
In my experience, the lawyers mostly warned the clients and the clients did it anyway.
Part of being a lawyer is simultaneously taking the blame for stuff like that while having done very careful diligence so that your malpractice insurance rates don't go up from clients successfully suing you :)
It's clear that there's a gap in existing licences that some regard as unfair. It also seems plausible that many projects could have dramatically better resources if the companies they are attached to could find a way to capture a fraction of their product's worth to their largest users. Just offering service with their competitive advantage being only the result of name recognition seems to work only for a very select group of huge projects. And even there, the likes of Canonical or SUSE show how hard it is.
Yet it is obviously challenging to write a license that adequately captures these facts. I think everyone would have something to gain from finding a way to make these situations work.
A required part of that solution may be for the community to interpret licenses not with the current they-are-trying-to-screw-us mindset but with, say, the "reasonable person" standard often used by the courts in contract/license disputes.
That's not going to be easy, considering "expect the worst and don't risk anything" always looks like sound advice, given that you will never know what you missed on the path not taken.
But the GPL's success should be inspiring here: it was initially met with scepticism, especially among corporate lawyers. Their essential pessimism never changed (it's how they became corporate lawyers in the firs place). But as it happened, it was enough for just few to take the risk, and subsequently creating precedents in court affirming the GPL, that made the concept cross the chasm to being palatable even to initial sceptics. Once courts fill in the questions of interpretation currently clouding these (necessarily somewhat abstract) licence, some doubts may dissipate.
(VCs please form an orderly queue. Priority given to investors willing to pay in Bitcoin or Monero. Contact deets in profile...)
I really hate MongoDB. I’ve been burned by it consistently for the past half decade or so, across several companies, data sets, ops teams, and underlying hardware. I’ve just decided that fundamentally MongoDB doesn’t work.
How would you go about writing a customer facing query builder that is analogous to the MongoDB aggregation pipeline with SQL?
With MongoDB I could conceivably generate/store a JSON object for such a query. In SQL it seems a lot more obtuse to do.
It doesn't need to be manual, only in a layer above/outside PostgreSQL. There are solutions that automate leader elections for any secondary-promotable-to-primary system (not just PostgreSQL), just not built into PostgreSQL.
We looked for about two years, on and off, to setup smoother, less-manual HA for our PostgreSQL setup. We ended up writing some, as you say, "tools / plumbing to overcome those issues". By far, though, the most time we spent on it was been spent in reading, testing, and getting to understand how things work.
After everything, unfortunately, no other system fit our requirements. Many came close in their marketing copy, but on closer look, every system had caveats. Ultimately, PostgreSQL is the only system I could still trust to do the right thing. In fact, the solid foundation that Postgres provides is why I can trust third-party layers (similar to Stolon and Patron) to focus on the job of switchover correctly without losing or otherwise messing with my data. In fact, I can even switch which tool I use, without it affecting my data.
The little plumbing we've written over Pg's built-in replication allows us to horizontally scale using logical replication and assuredly have HA using physical replication. At the end of the day, any shop that does anything important with data at scale needs to know how their data is actually being treated, irrespective of what the marketing promises. Hell, even when the data-store does not blatantly lie to you about keeping your data safe or uncorrupted, you can lose data due to bad use of tooling or explicitly-set unsafe configuration. "I'll just use this; it'll solve all my problems!" is rarely a thing to blindly believe when dealing with important data.
And speaking of Postgres HA management, master promotion, etc. there are several tools like https://github.com/sorintlab/stolon available.
Having said that, for someone who's already using Postgres, it's a great way to introduce some document-related behaviors (as opposed to strictly relational ones) by using the features it already has.
Even MariaDB is taking steps in this direction with many non-traditional relational types of storage options now available.
And if you have one of those tasks I congratulate you on finding a project with particularly unique data needs.
99% of the time, you're losing a lot from NoSQL, and you're not gaining anything. Most people who talk about NoSQL perf would never actually hit the perf limits of Postgres on their real life workloads.
‘Your honour, my argument is that I was copying this copyrighted software, for profit, without any legal license to do so. Oh wait...’
https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229013
To reiterate those comments, the SSPL only affects people who are offering the licensed software to the public as a service. This does not include any software that uses MongoDB as a component, even if it's a commercial SaaS offering itself. The FAQ we put out here makes that clear: https://www.mongodb.com/licensing/server-side-public-license.... 99.999% of MongoDB users are not affected by this license change.
People have expressed concerns that the 1) the FAQ is not the license, and 2) the language of the license does not make the intended responsibility clear enough. But it was drafted with that intention (and reviewed by outside counsel, with an eye towards being explicit without giving bad actors loopholes to exploit). Nonetheless, addressing those concerns is extremely important to us. This exact issue is being discussed on the OSI license approval mailing list, and we are considering very seriously all of the feedback.
The article anchoring this thread contains a lengthy discussion of copyright misuse and of impracticability. Those are also the subjects of discussion on the OSI mailing list, where Heather Meeker, writing on MongoDB's behalf, refutes claims that are similar to those made in the article. In particular, the SSPL is not trying to make people release substrate infrastructure, or adjacent tooling, under the SSPL. Consider the last line of section 13: "...all such that a user could run an instance of the service using the Service Source Code you make available." This means that as long as the Service Source Code you release is enough for anyone to run the service, you've fulfilled your obligation. As an example, you would not have to somehow be able to offer CircleCI under the SSPL (an impossibility), as long as your tooling that orchestrates its use is public, because anyone can use CircleCI.
It's our hope that these discussions will lead to an accepted understanding of the actual obligations of the SSPL. The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL. Thanks for helping us with that.
...while the license itself absolutely does not. I can read the GPL and tell what's expected of me, but I have no idea how to interpret clauses like:
> Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network,
Explicitly calls out allowing users to access MongoDB.
> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,
Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.
> or offering a service that accomplishes for users the primary purpose of the Software or modified version.
Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.
FAQ be damned, it's the license itself that's clear as mud.
> The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL.
Engineer to engineer, do you understand why so many of us find this uniquely onerous?
I make no claim that the SSPL is as easy to understand as the GPL. It's not. IMO the GPL's domain is such that it's easier for it to capture its intention succinctly. Do you link your software to this library? No? You're in the clear. You do? Then your software has to be released under the GPL.
The SSPL wants one thing: for people who make software available as a service to release their service stack under the SSPL. The problem is that defining "as a service" too narrowly makes it easy to circumvent. Imagine you used a really narrow definition, something along the lines of "running and managing an unmodified version of the software on behalf of someone.” It would be easy to add a single junk feature and get out of that obligation.
Every ambiguity you cite in the license is precisely crafted to thread that needle. Lawyers can certainly debate whether it was done so effectively, but the way I see it, we are looking at competing design goals: 1) embody the above licensing requirements, and 2) be easily comprehensible to laypeople. In a perfect world, these goals would not be in competition, but as we designed the SSPL, it was clear that they are.
The language you cite in your concern here is a good example of that:
>> or offering a service that accomplishes for users the primary purpose of the Software or modified version.
>Does not explicitly mention MongoDB, except by contrast implying that if we offer a service - even one not MongoDB-based - that accomplishes the primary purpose of MongoDB or a fork of it, then we're subject to the new terms.
At first glance, that last phrase "or offering a service that accomplishes for users the primary purpose of the Program or modified version" is an astounding overreach; it seemingly attempts to obligate you to release completely unrelated software under the SSPL just because it provides the licensed software's behavior. But the mere fact of a license's existence cannot obligate you to its terms; you have to use the licensed software. So it follows that the clause only affects you if your "unrelated" software is used to provide the same functionality as the licensed software that you are using in the service. I.e. you wrap the software in a clean-room implementation of a connecting driver and then build an external proxy that offers an identical API to the wrapped software but uses none of its code.
I hope that example at least makes clear that the language used in the SSPL doesn't introduce ambiguity for its own sake, or as a means to drive users to commercial licenses, it is a byproduct of the need to counter real-world means of circumventing its requirements.
>> offering a service the value of which entirely or primarily derives from the value of the Program or modified version,
>Explicitly calls out interacting with MongoDB. My company's website is basically a wrapper around accepting a query from a user, converting that into the appropriate NoSQL query, reformatting the result, and presenting it to the users. Since our web server is more or less an abstraction layer from the underlying database, it sounds like our whole website would be subject to the new terms.
Looking at the example of your company's website, I would say with complete certainty that it is not affected. You are not making that database's functionality available to anyone, and no matter how thin the functional layers are that you put on top of it, the value you provide doesn't derive primarily from the value the database provides.
Now, without implying that the SSPL is so perfectly crafted that it needs no refinement, I'd like to present this thought experiment:
If the area that the SSPL seeks to cover inherently means that its language has to be less straightforward, but if also it is shown to be legally sound and confined to the territory we claim it to be, then is it a worthy endeavor to pursue? If so, what constitutes "shown to be legally sound" etc.?
Apologies if this has been asked a million times -- didn't see it in a skim of your linked discussions nor the FAQ.
MongoDB does not release the stack for Atlas, our SaaS. That's possible because we own the copyright to the source code -- we don't have to issue the software to ourselves.
The blog post we published announcing the change covers this, as well as our motivations and expectations in a lot of detail:
https://www.mongodb.com/blog/post/mongodb-now-released-under...
There's a big difference between a piece of free software being vital to your codebase and you simply selling that free software as-a-service.
and since there is no dual licensing or anything that says that the mongodb inc does not do what the license says...
My understanding of the license change is basically "if you use MongoDB to support any site, all software higher in the stack needs to be released as well".
Is that accurate?
If so, why can't an author make this part of the license?
The only grey area I see is if you offered some sort of database-as-a-service backed by Mongo but not explicitly sold as Mongo-as-a-service.
Source: 1 data point; the company I work for's legal team just said "no".
In a fraction of the time, you could convert to Postgres, with the added bonus that doing so will also be massively more fun than arguing with lawyers. Below, you mention professionalism too.
Always consider license changes based on the possibility of the company being bought by oracle, there should be a law about it!
I can’t think of a single Mongo-as-a-service provider apart from Mongo themselves. None of the major clouds do it, neither do the also-rans like IBM or Oracle. So I call shenanigans on them.
So... why does the blog post argue that it's unenforceable?
My understanding is that they are saying "you can't use copyright to enforce something that isn't part of a creative work".
If that's an accurate version of their argument, then why not? The agreement is a contract with copyright as one side of the equation, and some behavior on the other side. Why wouldn't you be able offer a license for a creative work contingent upon things unrelated to a derivative work?
1) It is problematic to use copyright infringement as a hammer to force people to release/relicense code that is not related to the copyrighted code. (That's the "misuse" bit)
2) If you try to do this via contract, there are lots of practical difficulties associated with actually releasing the code - the biggest of which is that you probably don't own all the code you would be required to release. (That's the "impracticability" bit)
I don't see that as the case here necessarily. TFA just points out to potential users that the license has changed and might necessitate dropping MongoDB from your stack.
(Read the license and consult your lawyer for details, of course.)
That sounds pretty squishy and likely to be broader than just the use case of offering Mongo as a service.
Any app using Mongo simply as a datastore on the backend can swap it out without altering their offering.
> Imagine that the author is hired by a large evil corporation and, now in their thrall, attempts to do the worst to the users of the program: to make their lives miserable, to make them stop using the program, to expose them to legal liability, to make the program non-free, to discover their secrets, etc. The same can happen to a corporation bought out by a larger corporation bent on destroying free software in order to maintain its monopoly and extend its evil empire. The license cannot allow even the author to take away the required freedoms!
If MongoDB does not say in a legally binding way that this is clearly not what they mean, an acquirer could very likely twist the clause.
Words like "primarily" and "including, without limitation" make lawyers nervous.
"If so, why can't an author make this part of the license?"
So let's separate out two questions implicit here:
Can you make this part of a license?
Would you win if you sued someone for violating it?
The answer to the first is clearly yes, you can license it however you want :-).
However, like most IP, in basically all countries there are limitations on how you are allowed to license things, to ensure the original goals of copyright are respected.
Those limitations are usually presented as defenses.
Van gave two examples of defenses.
There are others.
For example, patent misuse is a defense to patent infringement.
Here's a concrete example of patent misuse that may be easier to understand than copyright misuse:
You sell a thing that infringes my patent.
In order for you to avoid infringing my patent, I force you to pay royalties for 10 years (Rather than a smaller length of time).
But wait, the patent expires in 5 years!
Can I enforce this?
No. It's patent misuse. You cannot use your currently valid patent to force someone to pay royalties past the validity period of your patent.
Another example:
You have a product X that infringes my patent. I use my patent on X force you into an agreement to pay royalties on a product Y that doesn't infringe my patent.
Can i enforce this?
No. You shouldn't be able to use the patent on X to force me to pay royalties on something that doesn't use your patent.
To bring it back to Van's examples, the copyright misuse is similar to the patent misuse i just gave you.
You can't leverage your copyright on X to force me to do something with an unrelated thing.
The GPL and AGPL are very careful about this. The AGPL applies to modified versions (which are derivative works) and only extends to pieces that are derivative works. The GPL is the same - only the derivative works are touched. That is within the copyright rights of the thing that was AGPL/GPL'd.
How do you know it's unrelated to a given copyright?
If X could not claim any copyright rights over it, it's unrelated. This usually comes down to whether it's a derivative work not because the other rights are not very broad in coverage.
Here, the license is taking X, and saying "You must do something with unrelated thing Y, which is clearly not within the scope of copyright of X". So I am trying to use my copyright right in X to force you to do it. Note: No lawyer believes there is any reasonable argument that completely and totally independent piece of software X that does say, monitoring, is a derivative work.
So that's a good start on copyright misuse :)
(The other prong is about whether it restricts competition, which they already admit is their goal here)
With the GPL, you couldn't distribute software that links (at runtime) to GPL software, without open-sourcing your software as well. This is because, linking another piece of software to a GPL'd binary means you're creating a "derived work". That's why they made the LGPL (the "lesser" public license) which allows being linked to from closed-source works, without being considered a derived work.
With AGPL, they seem to have gone the opposite way from LGPL: it seems to have extended the definition of "derived work" to include software that accesses the covered software over the network. If that's the case, doesn't that mean you just plain can't use MongoDB in the backend your own closed-source website (without open-sourcing your site's code?)
1. You can modify GPL code as much as you want, and as long as you don't distribute the software, you do not need to make the modifications available. If you distribute the software, you are required to make your code available.
2. The AGPL extends the definition of distributing the software to making the software available over the network. This means if you modify AGPL software and then make it available over the network (as SaaS, for example), then you are required to make your code available.
Doesn't this apply transitively? That is, I made MongoDB available over the network to my web tier (thus creating a derived work), and made my web tier available over the network to your browser (thus distributing it), thus, haven't I transitively made a derived work from MongoDB available?
I ask because this exact scenario seems to be what makes the company I work for so scared of AGPL. It's not necessarily cut and dry, but it's a scary enough possibility that we just ban it outright.
Now, the risk that a court might decide your software is a GPL derivative because it links GPL software might be enough to dissuade your company from using GPL software altogether.
LGPL makes it explicit that you can link against the software without making your software GPL/LGPL so it removes that risk.
And that's not what the AGPL is about. It's not extending the definition of what a derived work is, that is completely outside the hands of the license, it's a matter of copyright law. The GPL says if you distribute GPL (and by extension GPL-derived software) you must distribute the sources too. The AGPL says if a user accesses AGPL (and by extension AGPL-derived software) over the network, you must distribute the sources to that user. It doesn't mean that if a user uses unrelated software to access AGPL software, that unrelated software is somehow derived from the AGPL software.
Are you referring to the discussion between the author of CLisp and Stallman about GNU Readline, by chance?
https://github.com/JoshCheek/clisp/blob/master/doc/Why-CLISP...
Where would that put existing MongoDB released under the SSPL? Surely not public domain, so where?
I'm going to short circuit a lot of nuanced case law and differences between jurisdictions/courts here to give a clear answer:
Usually these things are written so the clauses are severable.
The court would then most of the time just remove the invalid pieces and leave the rest intact.
If it is not severable, the contract stands or falls as a whole.
If it falls, nobody is a valid user (though surely would be given time to stop or for mongo to fix it).
Why?
The default state of copyright is that only the owner has the rights.
If you invalidate the contract/license granting you non-exclusive permission to those rights, you no longer have that permission at all. So you have no right to be using it.
note: Any such court decision would only apply to the relevant court jurisdiction (IE if it was a district court decision, it would only apply to the parties)
It would just be persuasive evidence to other courts.
Practically, that is probably dealt with via a blog post and a retreat to the AGPL, but still.
Interesting. I've never delved that far into misuse but that makes sense. Is that piece a US specific thing or common in others?
As you say it would not have too much practical effect since it's curable trivially. You'd get a few hours of unrestricted mongo use, maybe, but I bet the official order would post-date the blog post fixing it :)
I’m not a lawyer, but I wouldn’t expect that to be a valid defense. If you can’t comply, don’t use it.
> "an occurrence of a condition, the nonoccurrence of which was a basic assumption of the contract"
Impracticability is not a defense against signing stupid or damaging contracts; it specifically releases a party when circumstances change such that a contract is no longer reasonable. Standard examples are things like the outbreak of war or a supply chain collapse, which don't render a contract literally impossible to fulfill but do place fulfillment outside the domain of any reasonable effort.
Defending against conditions which were already in place when a contract was signed is far harder, and even impossibility is not necessarily a defense if the impossibility is obvious at the time of signing. The only common defense I know of against conditions present at the time of signing is illegality, which of course comes up quite often with things like noncompete clauses.
The misuse complaint at least looks plausible, but I'm pretty baffled by the appeal to impracticability.
In the ensuing lawsuit, Service raises misuse and argues that the scope is ambiguous. Leaving aside the misuse argument, a court could either a) find for Service, thus restricting the scope of the code to be delivered, or b) find for MongoDB, thus giving rise to an immediate defense of frustration/impracticability, which would undo the contract.
I generally would trust his view on whether he thinks he could make out a defense or not.
It's better now, but very few things worry technical people more than a database that loses data. It's hard to get past that early impression.
> This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion that the write has probably occurred, or might later occur, or perhaps will occur, be visible to some clients, then un-occur, or perhaps nothing will happen whatsoever.
> We note that this remains MongoDB's default level of write safety.