Hacker News Reader

Comment by kellengreen | Hacker News Reader

Perhaps I'm just being naive, bug I still fail to understand the animosity towards the SSPL license.

The wording in sspl is awkward in its vagueness of its scope, specifically this clause:

> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available

For example providing SSPL software running on AWS as a service is probably/possibly license infriging because you are not able to provide source code for all the stuff you are using.

In practice probably even the most well-intentioned service provider can easily be trapped by that clause.

For instance, does it mean you can only run on an open source OS if you are providing it as a service, for instance? I guess not...?

Personally, as an open source user, I want to be able to pay whomever I want to host a product I'm using. The SPPL seems intended to prevent this. Like it's intended to prevent cloud providers from offering it as a serivce, if it didn't do so successfully under the exact terms, they'd change the terms to do so, because that's the goal. Whereas in fact as a user, I want the freedom to pay whomever I want to host it for me, if it can effectively only be self-hosted (whatever that means!) or hosted by officially licensed vendors, that's not what I'm looking for in open source, I don't want hosting-provider lock-in.

So, while we could legalistically look at the exact terms, I'd rather just have a license that is not designed to discourage/limit/prevent one of the things I want to do with the software, which is of course why we choose open source in the first place.

You can still host mongoDB anywhere you'd like and manage it yourself. What they would like to prevent was AWS and the like offering "MongoDB as a Service", because that's how they make money and fund development of the product.

If you enjoy freedom in open source and avoid lock-in, you will probably be hosting Mongo on an EC2 instance, for example. SSPL provisions don't apply to that.

This is not practical for many organizations which would want choice of vendors rather than do it inhouse or be hostage to MongoDB Inc.

It would be better if the license straight up forbid offering it as saas instead of hiding that behind conditions that are practically impossible to comply with completely.

I would like the freedom to choose to use MongoDB from a MongoDB as a service offering, not being limited to only certain licensed service-providers. That is the kind of freedom I choose open source for.

I'm wary of it because "make the functionality of the Program or a modified version available to third parties as a service" is vague.

If I have a web app that persists data in MongoDB and lets users query it in a complicated way[0], but doesn't provide an outright MongoDB-as-a-service implementation, it's still arguably making its functionality available. I don't trust them to enforce the edge cases fairly.

[0] For example, a custom report builder for an inventory management system, or a query builder for a CRM

This sounds like the least arguable edge case possible even if they were interested in chasing it (which they wouldnt be).

Although I admit that it's unlikely they will sue you for a product that isn't just a database, you shouldn't build your product on the (perceived) goodwill of the MongoDB developers.

Meanwhile, half the world start-ups base their entire tech stack on the goodwill of amazon and google, not to pull the rug from under them in hundreds of legal ways.

Using your definition of "goodwill" means basically everything on the Internet is based on the goodwill of some other entity. I think that paying for a service pretty clearly moves it out of the "goodwill" category.

They wouldn't be... until they go under.

Then the vultures will be happy to shake folks down to pay for the licensed version or a law suit. Merit doesn't really matter, they have a claim and fighting it will cost you. They'll just bank on you preferring to pay for the license.

They may not go after the mom and pops, but they'll hit every Fortune 1000 (and probably whether they use MongoDB or not).

Also unlikely. Vultures go for easy pickings.

MongoDB's page says this "includes, without limitation, enabling third parties to interact with the functionality of the Program ... remotely through a computer network". That would include all (web) apps with a mongodb connection. It then adds "offering a service the value of which entirely or primarily derives from the value of the Program". That's the vague bit for me.

FAANG are pretty explicit about hating AGPL and SSPL coz they kind of target them. That leads to a lot of second order animosity.

It makes no sense to use FAANG in this context.

It's the cloud providers that are the target of the license, specifically AWS.

One of the "A"s in "FAANG" is the same "A" in "AWS", so it does indeed make some sense.

And Google (GCP).

But not Microsoft, to which Google is a distant third place as far as the cloud goes.

Plus, isn't it MAANA now? (Meta and Alphabet)

My take is simple - DBaaS is the leading way databases are going to be confused in the future and SSPL ensures MongoDB is akin Proprietary Databases in this deployment mode - same as with Oracle while other cloud vendors can offer MongoDB they have to do it under the thumb of MongoDB Inc

Open Source is on other hand ensures you have choice of vendors

correct me if i am wrong but imo sspl is a superset of AGPL, because i have read somewhere that agpl fails if kept behind an api. you don't need to publish source and all that.

the problem with non-sspl licenses is, lets say with bsd, that you give the downstream developer the right to decide if your work is part of software which gives source to users when the concern of "Free software" is that end users MUST be given source.

when it comes to cloud providers, even if this agpl license is true, google already bans AGPL software but not aws but i'm not sure but that means they dictate to the end user with vendor lock-in and stuff.

anyways SSPL aims to accomodate even this loophole by making sure if you are a provider, you have to provide source code to ALL software you use. this means, for an end user you can't be forced into a small free software carrot but still subject to rest of closed source.

i'd say this is a win-win for end users, intermediaries and developers don't matter when it comes to freedoms of end users

In the words of Matthew Garrett "There are many AGPL projects where you literally can't pay someone money to avoid the AGPL. There are zero SSPL projects in the same position."

https://twitter.com/mjg59/status/1354698533094318082

I would assume that this is a good thing.

In practice the original claimed aim of the license does not matter that much.

Thankfully there are other licenses similar to AGPL, like BSL.

SSPL license is intended to stop cloud providers to offer it as a service. People will have to use MongoDB Inc.'s Atlas for that.

Or you can implement the MongoDB API like AWS did with DocumentDB.

SSPL license is more intended to stop the less sophisticated hosting providers.

Isn't that just MongoDB frozen in time before it was re-licensed under SSPL? Or is it actually a completely new query/storage engine that is MongoDB client-compatible?

In any case, I don't really like any of Amazon's homemade databases after the disaster that SimpleDB turned out to be.

DocumentDB an entirely separate implementation built on Amazon's internal tech which just speaks the MongoDB wire protocol. If they use any pre-SSPL MongoDB code it's just incidental bits and pieces.

Side note: From my experiences with documentdb, during the fires I had to put out trying to migrate a large mongodb workload to it, it looks like its Postgres or Aurora-Postgres under the hood (based solely on duck-typing around features, identifier constraints, storage limitations, billing, etc)

My issue is more with the software than the license - I'm comfortable running postgres at scale, less so mongodb. This will be great for people like me and widen the range of software that I can use off the shelf.

I don’t understand, your problem isn’t with the license but the software, but you don’t explain why you prefer FerretDB’s software? Is it more reliable than MongoDB?

It doesn't make open source function as free labor for billion dollar companies. Look at the top contributors to OSI and look up that time a Facebook lawyer badmouthed anything but the most liberal licenses at FOSDEM.

Reply on news.ycombinator.com