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.
Words like "primarily" and "including, without limitation" make lawyers nervous.
> 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.
"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)
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 :)
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...