[nicole_express]

As a non-lawyer who's tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code "by default" you only have rights to use that source code through a license or contract, so it seems odd that any restriction on the terms would be misuse or detrimental to competition, when the option always exists to not use MongoDB.

This isn't me trying to argue against the article; I'm trying to understand the law as it applies to my profession.

[jillesvangurp]

This uncertainty and confusion is by design and the whole point of this license. It's designed to make people who are not lawyers consider getting a commercial license just to avoid the potential for legal headaches that may or not materialize.

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.

[toyg]

It is actually silly, because being “the only unpaid open source nosql” is a pretty good position to be in. It’s how MySQL became huge: by being “the only unpaid open source relational db” good enough for real work.

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.

[metheus]

Disclosure: I work for MongoDB.

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.

[jillesvangurp]

The problem with that statement is that it is your company's lawyers interpretation of what it is all intended to mean. Yet, it's not certified by the OSS foundation and there are now loads of articles trying to interpret what it all means, which suggests to me that this is not a clear cut case of this being all that clear at all. Either way, your company is trying to actively restrict how the software is used even further than the AGPL already did.

I'd recommend sticking with well understood OSS licenses. There are plenty of those. This one is neither OSS (until the OSS foundation says otherwise) nor well understood. Both are problems. Especially when mixing with GPLed code. It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license. I'd still argue that that was the main point. I'd suggest celebrating any successful use of your software instead of trying to constrain it.

My suggestion would be to use Apache 2.0 and try to get companies to take a commercial license based on the merit of added value in terms of support, extra goodies, etc. This seems to work well for others in the industry (e.g. Elastic that recently IPOd); it's well understood; explicitly compatible with GPL; and has none of the disadvantage of rolling your own license.

[metheus]

Much of what you say about the lack of clarity is fair, but we hope that those things will be resolved when the SSPL gains OSI certification. In the meanwhile, we will do our best to 1) listen closely to the specific arguments as to what is unclear, and 2) attempt to dispel what we see as misunderstandings, often prompted by what is essentially FUD.

I appreciate your suggestions on what other licensing options we have. I think you really get what we are trying to do. That strategy is exactly how MongoDB has sold its enterprise edition for years. With apologies if I'm pointing you to something you've already read, we think the current landscape of the tech industry makes that insufficient, as our CTO's announcement post goes into: https://www.mongodb.com/blog/post/mongodb-now-released-under...

Anyhow, I do want to address this:

> It creates all sorts of headaches. And conveniently your company's way to solve that is a commercial license.

I think this is unfair. Everything we have said about the SSPL makes clear that it has one very exclusive set of targets in mind: large scale cloud providers with the means to strip-mine not just MongoDB, but any open source project with significant traction. And the one actual data point in this conversation supports that position: fatbird posted that they were on a sales call with MongoDB recently, specifically asked if they were affected by the license change, and were told "no". Is that a legally binding rider to the SSPL? Of course, not, but if the plan for the SSPL was to use it to wring money out of community users, wouldn't the answer have been "yes"?

If you've already read that announcement post, or if you now do, would you let me know if it makes anything clearer?

[jillesvangurp]

> I think this is unfair

I'm just parroting the sentiments here. This is how this move is perceived.

I think your CTO is wrong on this. This situation is not something that is going to improve with more blog posts, explations, or proclamations from your c level executives.

So, a wise move would be to roll this back ASAP and withdraw the SSPL.

This license is no a solution to Mongo's revenue problems and may actually make things worse. It sure doesn't solve any problems your users are having so whatever this is, it is not in their interest.

[thawkins]

Thats exactly how our legal dept intepreted it when it was announced. It took me several days to calm them down, including having to write up a migration plan to mitigate the risk.

[dragonwriter]

> As a non-lawyer who's tried to understand copyright law, this analysis confuses me; my understanding was that in the realm of source code "by default" you only have rights to use that source code through a license or contract, so it seems odd that any restriction on the terms would be misuse or detrimental to competition

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.

[xoa]

>my understanding was that in the realm of source code "by default" you only have rights to use that source code through a license or contract

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.