21–30 of 231 posts
Anyone surprised? Of course you can choose a non-free license for your code, but it comes with consequences. One of them is that Linux distributions that value free licenses will no longer act as your distributor.
This comment sounds like RHEL's license is more 'free' than Mongo's, which is not the case, imho.
If I were to ever use a NoSQL database for a new project I'd aim for MIT / 2-clause BSD based projects instead. PostgreSQL has no issue being BSD-like licensed (all this time I thought it was BSD or MIT, turns out it's a similar license instead). It saddens me RethinkDB couldn't compete more with MongoDB.
This seems like a non-issue to me...? The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. I'm a debian user, but their redhat installation instructions are similar: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-... I guess it will be a small speed bump for people experimenting their first time, but I've never had an…
> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. If you go with a distro package, you will get both the benefits of security updates…
Why should that be a problem if you use the official repo, handled by MongoDB themselves?
Earlier quoted context omitted.
> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. If you go with a distro package, you will get both the benefits of security updates…
>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. Why should that be a problem if you use the official repo, handled by MongoDB themselves?
now they'll be forced to also have one with mongodb (if their deployment is critical enough to already have red hat support they'll probably just caugh up the money)
Earlier quoted context omitted.
> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. If you go with a distro package, you will get both the benefits of security updates…
>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. Why should that be a problem if you use the official repo, handled by MongoDB themselves?
Let's say you're using version 1.1 of some software and you're hit by a remotely exploitable unauthenticated RCE.
You want to patch it, but the vendor says that the only fix is to update to 2.0.
How quickly can you adjust your software to work with that major release that might contain non-backwards compatible changes? Are you going to be quicker than the time it takes malware authors to write bots to hit that RCE?
There's also a second example which is automated updates: Our infrastructure automatically applies OS package updates via `apt-get`.
Thanks to Debian only ever updating packages for security reasons and only very rarely shipping new bugs, this is an actually workable practice.
But once you start adding 3rd party vendors who, for example, believe that once puppet 4 is released it's totally safe to just publish puppet 4 as a replacement of puppet 3 previously in the 3rd party repo, this becomes a very dangerous practice.
It seems[0] the new MongoDB license is basically non-free and it would make no sense to include it in RHEL8. I hope Debian and other distros follow suit as a result if they come in agreement. It's sad that the license change all resorts to greed basically, as if Oracle took over MongoDB. If I were to ever use a NoSQL database for a new project I'd aim for MIT / 2-clause BSD based projects instead. PostgreSQL has no i…
It's essentially "we convinced the stock market that our company tripled in value over the course of a year, and now we have to tell them what business model is behind this value growth" [1].
Earlier quoted context omitted.
This comment sounds like RHEL's license is more 'free' than Mongo's, which is not the case, imho.
Really? It's so non-free that you have CentOS.
It seems[0] the new MongoDB license is basically non-free and it would make no sense to include it in RHEL8. I hope Debian and other distros follow suit as a result if they come in agreement. It's sad that the license change all resorts to greed basically, as if Oracle took over MongoDB. If I were to ever use a NoSQL database for a new project I'd aim for MIT / 2-clause BSD based projects instead. PostgreSQL has no i…
Earlier quoted context omitted.
> The installation instructions I've always followed for MongoDB start with importing a key, and adding their official repo to my source list. Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. If you go with a distro package, you will get both the benefits of security updates…
>Going with the maintainer's repo means that you trust the maintainer with providing security updates for the version you have installed or you trust them with providing a useable upgrade path. Why should that be a problem if you use the official repo, handled by MongoDB themselves?
I happen to be in the latter position. Developers at both my employer and my previous employers generally cannot just install whatever they want, mostly for longevity/support reasons (at my current employer there's a way for developers to import outside code into the monorepo, which means just this week I'm cleaning up Node 0.10 and Go 1.3 from the monorepo...). They go through a team that builds them a system they can use. And that team strongly prefers to get software from our Linux distro than from third parties, because every single team has their own preferred third parties to get software from.
I do agree that for a shop that's running a single big web application with Mongo as the backend, they're probably installing it from upstream (and happier with that), but that's not the only use case.