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.
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
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.
> ...
> [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.
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 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.
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.
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.
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...
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.
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.
"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?)
Where would that put existing MongoDB released under the SSPL? Surely not public domain, so where?
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.
