Live data from Hacker News

MongoDB's Server Side Public License Is Likely Unenforceable

processmechanics.com

61–70 of 245 posts

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#61
post #20
post #8

Earlier quoted context omitted.

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…

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

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#62
Only a data point here -- after I read about this license change on HN, it took me about 2 hours to struggle over the issue, discuss with my team, and switch from MongoDB to PostgreSql. We are very lucky in that we were into this project for only two months, prototyping and learning the ropes with MongoDB schema. With PostgreSql now, everyone feels secure in a familiar territory. Yes, we have to make changes and its not rocket science to move over.

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.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#64
post #58
post #51

Earlier quoted context omitted.

Well, according to the article the second problem is directly inherited from AGPL.

Not quite. There are administrative problems with the AGPL, which are inherited here. But it is the scope of this license that pulls in these new defenses.

I'm sure they will address your concerns in SSPL v2. But make no mistake, you can't win here.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#65
post #63
post #56

Why isn't a straightforward solution to the "impracticability" problem just a "to the extent possible" or "authorized"-type predicate?

This would significantly ameliorate the problem.

So then, really, a big part of the critique here is that the SSPL is simply not written very well?

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#66
post #26
post #13

Earlier quoted context omitted.

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

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.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#67

I never understood all the hate mongo gets. Like any tool, if people simply took the time to understand it and use it correctly, maybe they wouldn't run into issues.

MongoDB made some very sketchy, undocumented (or poorly documented) technical decisions in its early years that placed data at great risk. 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.

early?

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

- http://jepsen.io/analyses/mongodb-3-6-4

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#68

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?

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 ensu…

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

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#69

Earlier quoted context omitted.

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 ensu…

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.

Re: MongoDB's Server Side Public License Is Likely Unenforceable

#70
post #34

Earlier quoted context omitted.

While I like relational data and I _love_ Postgres specifically, there are some tasks and contexts for which non-relational stores are better suited.

I'm sure that there are tasks for which non-relational stores might be better suited, but pretty much anything MongoDB does, Postgres does it better and in a more performant way (esp after the optimizations to the JSONB data type in the last few major releases).

This is a very bold comment, explain how you scale write, do HA in pg?
Post reply on HN