51–60 of 245 posts
Isn't it just so that the Mongo's SSPL is a natural extension of AGPL, modified to make it cover things that wouldn't otherwise be considered a derived work (which is exactly what FSFs interpretation of GPL does for more typical, 'single-host' situations), and inheriting the AGPL's problems?
I'm not sure what the question is, but the AGPL is very carefully drafted to avoid the problems Van is talking about.
I honestly don't see how this can pass OSI or DFSG approval. It's a blatant violation of rule 9, which prohibits restrictions on distribution of other software.
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...
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…
Where would that put existing MongoDB released under the SSPL? Surely not public domain, so where?
Use Postgres, problem solved.
> accused infringer would then, quite rightly, plead impracticability 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.
I wish the article had taken this question more seriously. Impracticability is a defense under contract, but a fundamental requirement in the US test is: > "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…
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.
Earlier quoted context omitted.
I'm not sure what the question is, but the AGPL is very carefully drafted to avoid the problems Van is talking about.
Well, according to the article the second problem is directly inherited from AGPL.
Use Postgres, problem solved.
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 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.