I'm not sure what "eat section 13 of Mongo's license" means, but if you're asking whether you should self-host Mongo or pay Mongo Corp to host it, I would say the latter. It's not that expensive, they have a nice management UI, failover, performance hints, backups etc..

And I say this as someone who doesn't like Mongo DB and believes it's almost always the wrong technology for business to use. But if you're using it, might as well get the experts to host it for you.

> I'm not sure what "eat section 13 of Mongo's license" means

Buncha weeks ago I had a paranoid fit about the legalities of this app I wanna try to launch. I read some conserning things about the MongoDB license, mainly that the open source initiative didn't approve it bc Mongo pulled out. I read the controvertial paragraph and now I am 80% convinced that I'm not allowed to self-host a MongoDB server for my own profit.. I'd have to pay.. which why should I when SQL is free. BUT I DON'T WANNA USE SQL. And frankly MongoDB wasn't living up to the stresses I wanted from it but Dgraph does.

Asking for help on stackexchange didn't do me any better https://law.stackexchange.com/questions/74510/can-i-use-mong...

I was planning on self-hosting my Dgraph database anyways, and if this app actually ends up being something, I would beable to calculate milestones that I'd need to reach before considering upgrading to Dgraph Enterprise. Now I'm more worried about future support. Is Dgraph going to be sunsetted, and will I have the features I might need in the future. IDK I think I just freaked out about something I didn't understand, sry guys.

IANAL but from what I know about Mongos current license (Server Side Public License) the restrictions of section 13 only apply if you are making a service with the express interest in providing DB functionality directly to your customers/users. IE: If you are making a Database as a Service platform, similar to Mongo Atlas or AWS RDS.

If you are just using mongo as a backend DB to fulfill some other internal requirement in your application, like general CRUD operations, then you are fine.

Arite, now the tally is even. I've heard the same number of people say to me that it's safe to use Mongo to power an app so long as I don't expose it, as have told me that I can't because I have to opensource all of my code that interacts with Mongo.

Euxodus is right. As long as you’re not building a product where the primary value of it is just delivering MongoDB as a service, you’re fine. There’s an FAQ that addresses that and more here https://www.mongodb.com/licensing/server-side-public-license...

I suggest to differentiate between selling MongoDB as a service (which would break the SSPL) using MongoDB as a database in your solution where you bind your application to the MongoDB driver that are licensed under Apache 2 (and which is the reason the knock offs can use MongoDB drivers and state they are MongoDB whatever compliant and be not because their stuff has nothing to do with MongoDB server but I digress). Nothing prevents you from utilising MongoDB Community in your own project/solution as DB backend.

What does “eat section 13” mean? The SSPL part? Are you looking to offer a cloud-based managed MongoDB database service to the public? If not, you can do pretty much anything you want with the code. There has been a lot of FUD posted but really, taking the community code and offering a parasite service like Amazon did with other databases is the only thing prohibited by section 13. And unless you have a lot of energy and time you probably can’t be competitive with Atlas, their managed service, as it has a lot of stuff built around the database. Just my opinion, but I am curious about the “eat” part. Of course if you are just allergic to anything different than pure Apache 2.0 regardless of the fact that SSPL has no business impact on you, that’s completely ok

You can use something like Amazon DocumentDB.

Or understand that MongoDB's license is kind of a necessary evil that I guarantee DGraph will likely implement at some point. Amazon's embrace and extinguish approach is too successful to ignore.