MongoDB Switches Up Its Open-Source License (techcrunch.com)

MongoDB is taking action against cloud giants who are taking its open-source code and offering a hosted commercial version of its database to their users without playing by the open-source rules. The company announced today that it has issued a new software license, the Server Side Public License (SSPL), "that will apply to all new releases of its MongoDB Community Server, as well as all patch fixes for prior versions," reports TechCrunch. From the report: For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don't apply to them. Instead, this is about what MongoDB sees as the misuse of the AGPLv3 license. "MongoDB was previously licensed under the GNU AGPLv3, which meant companies who wanted to run MongoDB as a publicly available service had to open source their software or obtain a commercial license from MongoDB," the company explains. "However, MongoDB's popularity has led some organizations to test the boundaries of the GNU AGPLv3."

So while the SSPL isn't all that different from the GNU GPLv3, with all the usual freedoms to use, modify and redistribute the code (and virtually the same language), the SSPL explicitly states that anybody who wants to offer MongoDB as a service -- or really any other software that uses this license -- needs to either get a commercial license or open source the service to give back the community. "The market is increasingly consuming software as a service, creating an incredible opportunity to foster a new wave of great open source server-side software. Unfortunately, once an open source project becomes interesting, it is too easy for cloud vendors who have not developed the software to capture all of the value but contribute nothing back to the community," said Eliot Horowitz, the CTO and co-founder of MongoDB, in a statement. "We have greatly contributed to -- and benefited from -- open source and we are in a unique position to lead on an issue impacting many organizations. We hope this will help inspire more projects and protect open source innovation."

Comments

I read section 13

[Anonymous Coward]

"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.â

That is a broad category that includes a *shitload* of software that has nothing to do with the source code of Mongo DB.
The lawyer who devised that nonsense clearly has some pals in the field who are looking forward to big lengthy but more importantly expensive legal discussions on the subject.

If I write some robotics software to rotate backup tapes for my MongoDB centric service, that'd be part of the 'backup software' and 'storage software' according to that definition, but it's hardly a very clear direct derived work, so how can the license I receive to use MongoDB apply to it?

Re:I read section 13

[thesupraman]

Very much so, this could easily be read as 'anything that provides a service to a user, and accesses mongodb as a backend'
ie: 'software that uses mongodb'

Which pretty much means 'run far far away unless you want your WHOLE system to be OSS'

Perhaps thats their intention, however I doubt they have thought it through much..

Re:I read section 13

[Kjella]

If I write some robotics software to rotate backup tapes for my MongoDB centric service, that'd be part of the 'backup software' and 'storage software' according to that definition, but it's hardly a very clear direct derived work, so how can the license I receive to use MongoDB apply to it?

It's an EULA like the AGPL, it does not depend on the definition of derived work like the GPL/LGPL does:

This License explicitly affirms your unlimited permission to run the unmodified Program, subject to section 13.

I can make a license that says you can only use my software wearing a pink bunny suit. It doesn't mean the code has anything to do with the suit, it's just the terms of the license. In any case, the license seems mostly intended to ban SaaS without a commercial license without actually banning it. Because I would think 99.9% of all services have some form of closed source component in their stack at some level, not even RMS has gone this far.

Re:I read section 13

[_merlin]

I think it actually is the intention. They think they're at a point where they're embedded in enough places that they can change the license to make it impractical to use their product without paying for a proprietary license. Of course they still want to pay lip service to being open source, and get the benefits of the community fixing their bugs. We'll now get to see whether MongoDB the company is truly providing value. If they aren't, a community fork under the old license (can't retroactively cancel AGPL on existing versions) will eat their lunch.

Re:Differences vs. AGPLv3?

[Etcetera]

The summary almost goes into the differences between AGPLv3 and SSPL, but then decides to fill space with a meaningless quote instead.

What are the practical differences?

“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.”

IANAL, but the basic issue seems to be that a modified version of the OSS under AGPL would have to be provided, but nothing else needed to make your SaaS version of the original OSS product work would be.

AIUI, under SSPL if you now sell "MongoDB Instances" for people to connect to, and that you'll cover replication and backups for those MongoDB Instances them using some nifty new proprietary add-on you built, then you're going to need to open source that replication and backup code too.

I don't think this would cover some large SaaS provide that simply *uses* MongoDB on the backend, only one that's *selling* MongoDB instances as a service in and of itself.

Violation of AGPL copyright?

[Anonymous Coward]

The AGPL itself is copyrighted too and contains right near the start:

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

The SSPL to AGPL comparison makes it crystal clear that this new SSPL is a slightly modified AGPL, with the FSF copyright notice and preamble removed and a MongoDB copyright notice added in its place, with not much more than one section rewritten. Did the FSF give permission for this, and if not, by what logic would this be allowed?

Re:Violation of AGPL copyright?

[Bruce Perens]

Actually, the GPL copyright issue might be moot. See this: https://www.gnu.org/licenses/g...

Re:Differences vs. AGPLv3?

[lkcl]

AIUI, under SSPL if you now sell "MongoDB Instances" for people to connect to, and that you'll cover replication and backups for those MongoDB Instances them using some nifty new proprietary add-on you built, then you're going to need to open source that replication and backup code too.

I don't think this would cover some large SaaS provide that simply *uses* MongoDB on the backend, only one that's *selling* MongoDB instances as a service in and of itself.

unfortunately this subtle distinction makes SSPL a non-free license. debian for example will be forced to move mongodb and anything under this SSPL license into the "nonfree" distribution section, thus ensuring that it is excluded from use in all and any debian critical core-level services.

it's a particularly sad state of affairs - a reaction to unethical corporate spongeing - that a major prominent software team has to consider changing the license to a non-free one just to be able to pay their developers to keep working, whilst corporations all around them make hundreds of millions of dollars in profits, using their work??

it's a repeat of the exact same pattern of corporate exploitation that caused me to stop working on samba-tng and exchange 5.5 reverse-engineering, 18+ years ago.

haven't these pathological spongeing corporations learned yet from heartbleed, shellshock and the lessons of the gentoo developer that was $45k in debt and had to go work for microsoft, and the GPG developer that was $10k in debt??