Hacker News new | ask | show | jobs
by appleflaxen 2799 days ago
I don't understand the line of reasoning. Can anyone give me a lay explanation?

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?

6 comments

No. If you take MongoDB and offer it as SaaS, the additional software that's part of your offering, such as monitoring, backup solutions, etc, have to be open-sourced, or you have to make their code available (since the chair of OSI defines what's open source).
I just had a call with MongoDB sales yesterday, and specifically asked if the licence changes impacts us, where we use Mongo as a datastore for our application, but we're not offering Mongo itself as a service. They were very quick and clear to say that the change is about those providers offering Mongo itself as a service. Using mongo in your stack to provide your service is not implicated at all.

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.

This makes sense, and I believe you, but lawyers being lawyers, I don't think any corporate legal team is going to even bother with trying. Easier to say "no".

Source: 1 data point; the company I work for's legal team just said "no".

Same fight here, but we're digging in our heels and bothering to convince the internal lawyer that it's not a problem. We'll win, but it takes time we'd rather not have to spend.
We'll win, but it takes time we'd rather not have to spend.

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.

What mongo says on a sales call is not going to be found usable in court.
The odds of anyone here ending up in court over licence terms for using Mongo as part of their backend, are so vanishingly small that to actually decide against Mongo on the basis of that chance amounts to professional malpractice.
For now. Their intent can change. Or they can be bought by oracle.

Always consider license changes based on the possibility of the company being bought by oracle, there should be a law about it!

Yes this also came up with my coworkers when we were discussing this. It's better to treat every software license as strict and malicious as possible because everyone can be eventually bought by Oracle and Oracle can sue you for misusing "their" license.
those providers offering Mongo itself as a service

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.

Statemens made by sales, are they legally binding?
Thanks for the explanation! That makes sense.

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?

Quick summary:

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)

The copyright owner can indeed license their work anyway they see fit. But often, the purpose of OSS seems to be "to share good software with the world." If that's the case, and then they change their license to a "... and you must also share _your_ work with the world," then they can't really complain when A) users stay on old versions licensed with the old license, and B) when use of their systems drops off lots.

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.

Not quite—if you offer MongoDB itself as a service, then yes. If you just use it on the backend, no.

(Read the license and consult your lawyer for details, of course.)

"offering a service the value of which entirely or primarily derives from the value of the Program"

That sounds pretty squishy and likely to be broader than just the use case of offering Mongo as a service.

It doesn't seem squishy to me insofar as you can't offer Mongo as a service and then swap Mongo out for a different product, while leaving your offering unchanged.

Any app using Mongo simply as a datastore on the backend can swap it out without altering their offering.

Yes, it clearly targets Mongo as a Service. I'm not clear, though, on whether that's where it stops.
Yeah, that throws off huge “what would Oracle do” red flags.
That's a good point—it likely trips the unofficial "tentacles of evil" test of the Debian free software guidelines, from https://people.debian.org/~bap/dfsg-faq.html :

> 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.

it also really doesn't sound like "if you use MongoDB in your streamingplatform/blog/whatever you need to opensource everything, which seems to be the gripe many a commenter is having.
Maybe. If there's more lines of code in the Mongo part than the other part, is the value "primarily" Mongo? What if I made a file upload/download site? Mongo might constitute the bulk of the value/lines of code/whatever.

Words like "primarily" and "including, without limitation" make lawyers nervous.

That depends on how you think a court would weigh the source of value of your offering; and any factor that makes MongoDB more valuable as a component before considering the license makes it more risky when you consider the license.
It's not you that needs convincing, it's the lawyers of the company that's acquiring your Mongo-using startup that need convincing.
That's not correct, the license only says if you make SSPL licensed software itself available as a service, you have to release the service code under the SSPL. Using the licensed software to build anything else at all is ok to do without releasing your code.
The problem is that we don't know how Mongo will choose to exercise this brand new license, and how courts will rule on them. I've brought this change to our corporate counsel and they are advising we stay clear of it.
IP lawyer here :)

"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)

I have a question about how derivative works are defined with respect to AGPL.

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?)

I think you're slightly off there. The AGPL doesn't apply to software accessing the AGPL licenced software over a network, it applies to the AGPL software that's being accessed. As in it applies when the software is being accessed over the network rather than when it's being distributed (as with the GPL). This is actually mentioned in the article.
I think you have this correct, as I understand it. Just to explicitly state the differences:

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.

> The AGPL extends the definition of distributing the software to making the software available over the network

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.

Runtime linking doesn't always equals derivative work. Some GPL enthusiasts would like it to be that way but it doesn't mean it is. As far as I know it's a murky legal issue. I forget the exact case but one counter-example was: you have proprietary library A. Someone makes a GPL implementation B with a compatible interface. You ship software C with instructions that users can use either library A or B. An example of this would be BLAS libraries, which have both proprietary and open-source versions. Software C is obviously not a derivative work of GPL library B.

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.

> I forget the exact case but one counter-example was: you have proprietary library A. Someone makes a GPL implementation B with a compatible interface. You ship software C with instructions that users can use either library A or B.

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...

Also the only part of mongo that is limked is the driver, not tbe database product. All the drivers are licened under apache 2 license, which is permissive, and largly just demands preservation of copyrigths and trademarks. It does not mandate source distribution for derived (linked) products.
Let's hypothetically say that a court agrees that this is copyright misuse.

Where would that put existing MongoDB released under the SSPL? Surely not public domain, so where?

Depends on how well written/what court decides to do.

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.

Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with.

Practically, that is probably dealt with via a blog post and a retreat to the AGPL, but still.

"Interesting thing about misuse, is that it prevents the enforcement of the copyright against even non-parties until the misuse has been dealt with."

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 :)

Probably US only, didn't look internationally.