At the outset, it sounds simple that MongoDB inc thinks why should some 3rd party cloud provider (AWS, GCP, DO and the like) be allowed to run MongoDB as a service and make money while MongoDB contributes the biggest part of the open source project that is MongoDB.
But, it feels like yet another fallacy. What really is an open source project then?
Say some developer X contributes to a project like MongoDB his/her open source code so that they can one day run MongoDB as a service and make money. At that time, he/she believe that status is true and submits their code. But, later, after the project is mature, the major contributor easily changes license at will, and the open source contributors walk away with nothing?
I'm not saying that MongoDB Inc, does not have the majority stake here. Just wondering about whether it is a "bait & switch"esque move?
Imagine if all projects did the same... Say Docker? later on chooses to say that you can use Docker for free but if you distribute your software through repositories supported by the daemon, then you need to pay up.. Wouldnt that be a loss for the contributors that are not working for the company?
Predictability: who's to say what MongoDB will decide in the future e.g. ask for more money and/or charge per vCPU + memory. Employing developers directly, on the other hand: here's an offer and vesting schedule - they know exactly how much they will spend for 3+ years, and get to control the roadmap.
> A lot of AWS's managed services are just off the shelf open source projects on the backend.
Amazon employee here. Amazon offers two different types of service. For a service like Amazon RDS then yes it is the standard open source project hosted and managed by AWS. The value add is that you don't have to administrate and back it up, etc.
For something like Amazon Aurora its a different story. Aurora is API compatible with MySQL and Postgres but it is designed internally to work quite differently, really designed for the cloud first. And the result is its up to 5x faster than the standard open source software and just better than the open source version in many ways.
Both as a former customer of AWS and now as an engineer at AWS I have always preferred the from scratch implementations by AWS over the hosted open source versions. I'd rather not use a forked version of open source. I'd rather use something built by AWS engineers from the ground up
> For something like Amazon Aurora its a different story. Aurora is API compatible with MySQL and Postgres but it is designed internally to work quite differently, really designed for the cloud first. And the result is its up to 5x faster than the standard open source software and just better than the open source version in many ways.
It's also noticably slower than plain PG in other cases.
I heard that AWS offered mongo XX million dollars per year to have Mongo included as a backend for RedShift.
They haven't touched it yet, because of its license.
Azure offers Cosmos DB advertised as a drop-in for MongoDB. I'm guessing Cosmos is Mongo in disguise, though I don't know if it really is, and/or whether MS has made a deal with Mongo or just think they can use the AGPL version.
For the record: I'm not a big fan of Mongo (the DB) but I think MongoDB, Inc. raises a valid point wrt. developers doing all the hard work including community building and a million other things, while "cloud providers" get all the money. This isn't sustainable, and we need a license which more clearly says "if you make money with it, you need to give us some", rather than using the bare AGPL license without further qualifications in the hope AGPL's "freedom" aspirations have the indirect effect of forcing commercial users and/or resellers to pay.
Fair point, but if you strip any money from product development, this implies you don't have a budget for further development and maintenance, except if you make it support-intensive. And for what gain? That very few cloud providers make more money and enslave customers into their walled garden? Cloud providers don't even need to provide QoS or support - they can just shrug and say "we're running an OS project as-is". If no money can come your way, then development and support is simply not sustainable.
The projects you mention: Linux+git development has good financial standing from companies who could be seen as going (or having gone) aggressively against commercial Unix from a business PoV. gcc thrived on freedom enthusiasm but has seen many, many patches from commercial vendors wanting their OS, CPU or whatever supported.
How much AWS shares its profits with GCC, qemu, etc? Not at all besides the bare minimum that benefits them.
(And don't misunderstand me, I don't see Mongo as some kind of underdog here, but making big money from software is hard, even if - or exactly because - valuations - and funding - are in the sky.
And AWS is fundamentally a different kind of business than what open source usually is. It has a compounded networks effects / economies of scale effects. And on top of that it has a closed source management layer, but that is largely irrelevant, except for Mongo in this case.)
Linux, gcc, git OSS projects are less concerned about capturing value from the economic activities enabled by them, which is why they were all set up as not-for-profit enterprises; the expectation is that donations will help cover their operating costs.
MongoDB on the other hand is a for-profit enterprise that took VC funding in the hope that they'd be able to cover their operating costs in the long term without donations.
The only way to do this is to capture some of the value offered by the NOSQL paradigm, but it appears that the cloud providers are beating them at that game, which is why they needed to change tactics, to guarantee their survival as a self-sustaining entity.
> I think MongoDB, Inc. raises a valid point wrt. developers doing all the hard work including community building and a million other things, while "cloud providers" get all the money.
I think MongoDB is free loading off the the community and developers. The developers don't get to use the software to make a profit without kicking some money upstream to mongo either. Is Mongo going to start offering money for bug reports and patches or do they get to freeload off of their community?
I think you're overestimating outside contributions to these types of projects. In my experience, they are typically minuscule, and mutually beneficial relationships when they do occur.
I wish it was Mongo under the hood. Our migration to Azure almost crashed and burned because, aside from the extortionate pricing model for Cosmos, their "Mongo API" is noticeably incomplete (in our case, they didn't support the array positional operator, and still don't [0]). Nowhere do they have an API compatibility checklist or anything articulating less than complete support for all features--the positional operator has been in Mongo since version 2.4, five years ago. (version 4 is what's current now).
IMO, Azure remains a garbage fire of half-finished features in almost every offering. We replaced Cosmos with a Bitnami-authored canned VMs pre-configured for a simple Mongo cluster (which make up a significant portion of "features" they offer), which failed to restart after the Meltdown cloud reboot because the Bitnami management software corrupted the disks. Now we just run our own VMs with our own Mongo instances and curse the day we were obligated to move to Azure.
IANAL, but I believe in this case a maintainer can just fork MongoDB from right before they changed the license, then new contributors can just contribute to that forked repo, creating an off brand “Non-goDB” that will get a lot of the updates that people want. This would fracture the development of the project and would be bad for everyone, but at least the open source community wouldn’t completely lose the project.
IANAL either but just to be pedantic, in theory I don't see what stops them from no longer distributing old versions under AGPLv3. Having distributed it at one point under GPL doesn't force them to continue doing so forever.
Of course that would be pointless as anyone who forked before the license change could continue re-distributing under AGPLv3.
But you can still offer it as a service, just as long as you opensource your infrastructure. The only thing it prevents you is profiting from lock-in of your services without sharing those profits with MongoDB. Very much in the spirit of open source.
Yeah, but how is that really supposed to work? I can see why MongoDB would want to do this, but how on earth is this really supposed to be implemented? Where do you draw the line? What I suspect is that you'll end up with a bunch of shell scripts for creating MongoDB instances...
MongoDB bets that anyone who wants to run mongo-as-a-service will ask them for a business license (instead of open sourcing their whole cloud management stuff), and they will work out a deal.
If you contribute to a project, you have no entitlement, moral or otherwise, to _future_ contributions to that project that others choose to make. Future contributions may be made under different terms, as you point out. The project might stop development, get forked privately, and you may never see active future developments distributed again.
This is self evident from the licences themselves but also clearly reasonable if you consider the proportions of contributions made. Why should a contributor get rights to all future work on a project made primarily by others solely by making a contribution?
> ...and the open source contributors walk away with nothing?
Nope. As others have pointed out, they walk away with the Free Software licensed version of the code to which they contributed, together with their contributions. This code base does exactly what it did at the time of their contributions.
I used to like permissive (OSI) licenses a lot more than restrictive licenses, but now I like copyleft better (for my own projects) because…
1. You’re still helping education, nonprofits, and individuals benefit from your work.
2. It’s still open source, so people will still be able to contribute and use your work in their own projects.
3. Companies that want to use your code to make money can do so, but only if they also help out the other “worthy” causes by contributing changes back.
In fact, I'm consider something more radical like a YUMMY license (you make money, I make money) - which has all the same benefits of being open source and helping worthy causes, except at least you get to make money when someone uses your work to do something that you might not even want, like selling ads.
I really like WTFPL as a permissive licence in these cases.
Small developers and companies without layers of lawyers will read the licence, see that it says "do what the ---- you want", and use your code accordingly.
Big companies with layers of lawyers will read the licence, blanch in terror, and either refuse to use the software, or contact you for alternative terms.
It's in small companies' interest to have their creations used and monetized by Google without anything being given back? I'm glad you're transparent about your own context here--it's appreciated, but I hope you can see that outside the walls of Google there's another world.
I'm not at all sure where you got any of that, it seems like you have an axe to grind.
You clearly didn't read the link i said which says our issue with WTFPL is with the lack of warranty disclaimer and with the rights grant (which is not likely to be valid in a number of countries).
You will find nothing, nor have i stated anything about the ability for google to use the code for "monetization" reasons.
It doesn't even enter the equation
It is very hard to take your comment in good faith as a result.
Our policy pages are clear on why we ban licenses, even things like AGPL. You'll note they are not economic concerns (IE google won't be able to monetize), but compliance ones.
(Of course, you should view these in good faith, they were originally written for an internal audience)
I can definitively state I have never banned a license at Google due to Google's ability to "monetize" the code, or even indirect versions of that (IE that if it became popular, it would hurt google's ability to do that).
All concerns are compliance ones.
Additionally, the pages i linked you to very clearly encourage people to contribute back as much as they can.
> Our policy pages are clear on why we ban licenses, even things like AGPL. You'll note they are not economic concerns (IE google won't be able to monetize), but compliance ones.
AGPL compliance wouldn't be that difficult if you remove making money from the equation. So indirectly your compliance concerns are based on economic concerns.
> AGPL compliance wouldn't be that difficult if you remove making money from the equation. So indirectly your compliance concerns are based on economic concerns.
This is simply false (on both points), and you haven't given any reason it would be true past "i feel this way". Even with direct support from our build system, AGPL compliance is incredibly difficult relative to GPL and other licenses[1]
This argument also amounts to "I know more about your job than you do", which, if you do, awesome!, please feel free to do it :) I'm actually happy to go do something else.
But i don't see evidence that this is true.
[1] For starters, we have to distinguish between what things , what are user facing, what kinds of users have access to them (IE internal services accessible only to FTE googlers are different from those accessible to TVC for AGPL purposes) , etc.
This is an incredibly difficult set of problems on the technical side.
Appreciate your response, but what's so incredibly difficult to open-source all the things when you're running AGPL software? You choose not to, which is fine, but it's still just you wanting to monetize other's work without giving anything to others to run yours, in turn.
First, Your assertion is basically not that compliance with AGPL is not hard, it's that "you could just do more than the license requires".
That is always true, even for non-open source licenses.
You could take MIT code and comply not just by publishing a notice but by publishing all of it.
I don't think that is a meaningful argument against the annoyance of having to collate and publish notices.
Imagine if you have a commercial license that requires you be able to allow them to look through your books to verify software licensing, that often has high cost.
Your suggestion is basically "why not just make your books public" (IE more than the contract requires).
I don't think that's a meaningful argument against the cost of compliance, because that's not about compliance with this license, but instead one that requires more.
The whole point of contracts/licenses is that they are a deal. What you are suggesting is a very different deal, and we'd deal with it a very different way.
No one knows what AGPL compliance actually means, whether money is being made or not. It has failed several lawyers' sniff tests for being potentially arbitrarily enforceable however the AGPL developer sees fit, and the general consensus is that we won't have any idea of what AGPL compliance even looks like until its had its day or three hundred in the court system defining what exactly its limits are (if any?).
I do understand your viewpoints. I just disagree that they're significant enough in practice to outweigh the value I see in WTFPL.
The lack of a warranty disclaimer isn't an issue in practice; my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law.
More important, to me, is what WTFPL says about my code: I'm not precious about it, I give it to you, I trust you to go do amazing things with it. It is a very humble licence. It says life is too short to get precious about licence wankery. Plus there's the side-effect that small companies and artisan developers can use it, while behemoths like Google won't. These, in my view, are all to the good.
I don't expect you to share that view, but for these reasons, WTFPL is a "good licence" for me. OpenStreetMap thrived for years with a WTFPL-licensed editor (I wrote/maintained it). No-one died, no-one got sued, and OSM became one of only four worldwide geodatabases. The main reason the current editing software isn't WTFPL (I started it but handed over to more talented developers pretty quickly) is that Intel wanted to use it, went "WTF WTFPL", and asked the new maintainer to change it. He did, but tagged the next release idiot-intel-lawyers. I laughed.
(IANAL, though I have spent way too much time over the past 15 years studying licenses and their applicability across different jurisdictions, again principally in connection with OSM and with its - very successful - licence change.)
Many countries don't have the US concept of public domain, including the one where I live ("in the public domain" actually means something quite different in British English). But the WTFPL also makes a statement and one of which I approve.
So similar to a clause in the license that says "don't use it for evil". Many companies will want a license that doesn't have that clause in it, because it is so ill defined.
I find it funny that Crockford gave Microsoft the rights to use his software for evil, requesting nothing in return. The clause really was just a joke.
Minor pet peeve, I understand that different people use open source differently -- but I would classify the license you're describing as source available. A FOSS compatible license can't carry restrictions on usage.
I'm assuming you already knew that and were just using the looser, more generic definition. Which is not a problem, I just have seen enough people get confused later on when somebody says, "well, technically, this isn't strictly Open Source", so I like to point it out for anyone else who's reading.
How would they litigate against a mega corporation? Mongo is a very small company compared to many cloud providers. They would be tied up in the courts for years and spend hundreds of millions and possibly drive the company into bankruptcy.
To legally fight in China pretending that something you can't see was modified is... hard. IMHO the only wrong thing about this move is trying to get it OSI approved, otherwise I can understand that they have concerns that do not apply to most normal users. However one should boldly say we are moving away from an OSS model, to a "available source" model where you retain most rights.
How is those going to affect China? If the old enforcement methods didn’t work with the previous sane-ish license, they certainly won’t work any better with the new monstrosity.
Now you don't have to pretend that they changed something without having any way to prove it. Now if the orchestration software is not open source, they can't use it.
They could just claim that their orchestration software is open-source (potentially w/o stating what it is), or just publish a stub set of scripts that plausibly work but that aren't actually used under the hood. I'm not sure this really makes things all that much clearer.
I'm not a lawyer but my understanding is that the AGPL does not stop you from offering it as a service as it does not explicitly say you need to contribute back anything that is not direct modifications to the server source code. But that's just how I read it.
This new license has language that allows the 'infringer' to pay their way out. This is a shorter path toward proving damages in a US court. This license is basically a litigation cannon being wheeled around to aim at people who are currently making the money that MongoDB wishes it were making.
You seem like you know something about rethink. I do not, and couldn't find this information but maybe you know?
One irritating feature of Mongo (and I suppose other db's too; orientdb does this) is that once it grabs disk space, it never lets it go. It'll reuse that space, but the OS will never see it again. (EG: If I store 10GB of stuff, and delete 9GB of it, the OS still sees all 10GB of disk used).
I'm not an expert in licenses, could someone weight in and explain how the AGPLv3 was being abused?
Did the mentioned companies follow the spirit of the license and were getting away with something the company didn't like or were they just improperly distributing the software, regardless of licensing terms?
Also:
"So while the SSPL isn’t all that different from the GNU GPLv3,(...) [it] explicitly states that anybody who wants to offer MongoDB as a service (..) needs to either get a commercial license or open source the service to give back the community."
Doesn't AGPLv3 already require open sourcing server side implementations?
“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.”
The "all programs you use" clause seems to make it extremely viral, perhaps unprecedentedly so. It seems to me that anyone not willing to comply with AGPL would be even less likely to comply with this. Not sure how that's supposed to be a good outcome, even for Mongo.
Distributions like Debian, Fedora, Ubuntu, etc. require that all software in their core repos be FOSS. It's not about their legal obligations but about their own policies forbidding proprietary software in their core repos.
Since the new Mongo license violates rule 9 of the DFSG, it is considered proprietary software by Debian's definition, and that means Debian's FOSS policy will require Mongo to be moved out of the core repos and into the non-free repo. Fedora and Ubuntu have their own policies which will have the same effect.
Mongo already provides their own repos, and recommends using that for install and updates. I don't think they care or anyone seriously wanting to develop something on/around Mongo does either.
Why is it viral? It doesn't require those other stuff to also be available under this license, just as source-available. Which means this is basically AGPL++.
That... is an impressive load of shit. So because I want to host MongoDB, I have to offer up the source for the Linux distro used to host the Jenkins server that I use to test it, huh.
Last week I was debating whether MongoDB is now completely obsoleted by PostgreSQL’s JSON datatype. As of now, I consider that no longer a debate.
If you've never had to enumerate every piece of software you've installed, you might not think so. In practice, it's a major PITA. And what if you're using a closed-source CI/CD or monitoring system, so that you can't comply with their bizarre terms?
No, I think the real goal here is to make it effectively impossible to use this in a business setting without buying a commercial license. I'm glad Linus and RMS didn't see it that way.
Original: your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software.
Also from the license, w.r.t. "Corresponding Source" definition:
===
However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
===
Not that this makes the issue any more clear or enforceable...
There was no abuse, there was only mongo not being able to make money in all cases they wanted to.
That's what they see as abuse. It isn't.
While they complain of bad actors, bad actors always act bad.
This will not disincentivize them (they are also often in a lot of interesting jurisdictions that would make it hard anyway).
Instead, this is really about making it completely unpalatable for normal actors to not pay mongo in every single case.
Otherwise, one has to believe that mongo is going to go off and sue a bunch of people now, which would be a horribly stupid business model.
Speaking as not a lawyer: there is lots of abuse of OSS infrastructure from big tech corps — because the AGPL isn't equipped for everything-as-a-service eating software licensing. If "abuse" were license violations, they wouldn't have to use a new license.
This feels a lot like when i hear about "GPL" abuse when it was specifically not designed for what people think is abuse (and that's not my view but stallman's).
Similarly, AGPL was not designed to require every piece of software around a piece of AGPL software to be open sourced.
Deliberately so.
Not doing so is not "abuse".
You may have different goals, and that's actually fine!
But it doesn't make following the license and what it was meant for abuse.
I'll also point out: In the history of my work on open source, by far the largest legal abusers of open source are startups. By many orders of magnitude. This is real abuse in the sense of clear license non-compliance. I worked on M&A at a variety of companies that acquired all sorts of different kind/stages of startups.
They rarely are compliant with even simple notice licenses (IE don't bother to post notices), let alone any of the more restrictive licenses.
Large corps often have legal departments that try to understand and consider and figure out what to do, even if they do it wrong.
So to me, every time i hear "large company open source abusers" i kind of laugh, because IMHO getting the startups to stop abusing open source would have a much more significant difference on OSS than getting 2 or 3 large companies to stop "abusing" it.
Abuse is taking all the free candy at a doctor's office. It might just violate a norm without breaking a law, but it's still abuse.
It's situational, but if you define abuse as "breaking a contract or law" we're not going to agree on anything about this.
MongoDB has _always_ wanted to make money when other people make money reselling their work. The AGPL doesn't really do what they needed, but their intent has been clear since day one.
Let's be real concrete here with no analogies:
I asked you to define what you see as abuse?
Give me concrete examples.
I explicitly pointed out to you a social norm, not a violation of contract. I did not define it as breaking a contract or law. I defined it in terms of the social norm that was set by the creator of the license, or the "spirit" of the license.
I want to understand what you see as "violation of that spirit", not the legal definition. As mentioned, most definitions i've seen here are explicitly not what the creator of the license intended (again, not what they wrote down, but what they intended).
It's hard to see something that doesn't violate the spirit of the license as abuse.
For example, i often hear about "not contributing back" to GPL projects.
RMS explicitly was okay with "not contributing back" in the broader sense, as long as they released their source code. He had no expectation he would get anything other than a pile of source that he would have to deal with. He just wanted to be able to hack it, so as long as it had the right stuff, he didn't expect others to care. He thought it would be nice for sure, but it's not "abuse".
(A great concrete example of abuse is usually binary kernel blobs that have deliberate shim interfaces. This clearly violates the spirit of the license even if the license says it may be okay.)
So far i haven't seen what you have defined as abuse especially by "large companies".
Additionally, I pointed out to you the notion that large corporations are the ones doing the abusing is wrong under almost all definitions of abuse, spirit, legal, aspirational, you name it.
Who are you to decide what is the norm being violated? What I mean by that was the entire point of open source and free software licensing is to codify the 'norms' that the authors found important.
Companies like Google, MS, Amazon are not violating norms but complying with them. When companies like MongoDB abandon these licenses its because they're incompatible with their business model.
Open Source is fine for them while they're making a market and developing a programmer user base, becoming popular with people who will not bother with a new proprietary database, mind you, but once they're 'popular' and need to increase revenue, the license gets replaced with a familiar , proprietary, one.
It's bad analogy, but the candy bowl in this particular example is "revenue available to companies selling this stuff". The cost to duplicate these things is 0, but the available income is fixed.
> Abuse is taking all the free candy at a doctor's office. It might just violate a norm without breaking a law, but it's still abuse.
Using your analogy, MongoDB is taking all of the free community that is around open source and changing the license after they have a community so they can extract/shakedown money from people. If anyone is abusive, it's people like MongoDB changing the license after they got lots of free contributors adding to mongodb.
AGPL: 'if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there.'
Some companies are illegally running a modified version of MongoDB while keeping their changes closed source.
As I understand, the new licence will allow them to do that if they pay a commercial licence (contributing to the project by financing instead of coding).
AGPL does not require the copyright-holder to license the work exclusively under the AGPL, only those that received the work under the AGPL. People and companies are free to receive from copyright-holders their works under different — even commercial — licenses, irrespective of which (and how many) (non-exclusive) licenses the copyright-holders have used in the past for the same works.
In the matter of allowing commercial licensing by the copyright-holder, the AGPL and this new license do not differ.
> While they complain of bad actors, bad actors always act bad. This will not disincentivize them (they are also often in a lot of interesting jurisdictions that would make it hard anyway).
Yes this is not going to stop the Asian cloud providers they talk about. It is truly aimed at AWS et al. If they came out and said that it would not sound as nice. Mongo just made a big move in the cloud space by buying mLab. They are looking to contain the competition.
Abuse isn't a legal concept here. It's condemnation of specific business conduct, specifically a kind of free riding. That's for businessfolk to debate. Lawyers read the licenses, but business managers decide how to use them, to what ends, and why.
The cloud competitors MongoDB professes concern about have sophisticated software license counsel. They're very good at reading licenses. That is part of the claimed problem: They were good enough to see and exploit loopholes in a dense, oddly drafted license like AGPLv3, which most others read as "free for free software only", rather than as written. They also have deep pockets, US legal nexus, and significant ongoing commercial use to enjoin. The latter make a wide target. But the former makes them too strong to sue on anything but firm ground.
I don't know what you mean by normal actors, but if there are a lot of them, and they're relatively small, and also potential Mongo customers, suing them en mass to make examples, RIAA/MPAA-style, isn't nearly as appealing as cutting big cloud providers offering MongoDB off from updates with a license change. Everything about these changes and the materials accompanying points to the latter.
I don't see Mongo announcing any litigation campaign for going beyond AGPLv3 permission. I do see Mongo drawing a new line in the sand, via a new license for new releases, that will be easier to defend against the specific competitors they see pushing the limits of the old line.
> Instead, this is really about making it completely unpalatable for normal actors to not pay mongo in every single case.
Or they might just release their entire stack, which is probably 90% open source stuff with 10% glue code anyway.
There’s more to running a business than just cloning a software stack. Any idiot can fire up an OpenStack based ‘cloud’, but that won’t make them the next AWS.
The article references cloud providers, "especially in Asia", frustrating MongoDb, does anyone know which companies these are or specifically what they have done which other did not?
The license is clearly based on (A)GPL which is copyrighted by FSF, and has the following notice: "Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed."
Does that mean that MongoDB is now infringing on FSF copyright of the license text itself?
Oh, sorry, that was a non-sequitur. The actual reason is that text doesn't mean you can't modify them and create new licenses, it means you can't modify them and still call them A/GPL.
FSF has historically let others make new licenses based on its own as long as they name it in a way that is not likely to be confused with any of the GNU licenses.
The FSF separately and specifically grants permission to modify their licenses under certain conditions (change the name and references to GNU, and remove the preamble unless you have permission): https://www.gnu.org/licenses/gpl-faq.en.html#ModifyGPL
From MongoDB, Inc's POV, its fine to run MongoDB in-house for the purposes of supporting some user-facing application. Coinbase would be a good example, they make a consumer product that uses MongoDB as the storage backend.
What is definitely not allowed is selling fully hosted MongoDB instances. E.g. (https://cloud.yandex.ru/docs/mdb/). To do this you will need to open-source all the supporting infra/automation code which will be a deal breaker in many cases.
The real grey area is a service like Parse or Firebase that is built on Mongo but offers a Mongo-like DBaaS. Is it against the SSPL to build a service like that? Or is MongoDB, Inc trying to force everyone to use its MongoDB Stitch service [0]?
I might be reading this wrong, but doesn't this qualify as a "super viral" license in that any code that in any way is part of the stack for hosting Mongo as a Service must be open sourced as well? Granted, a company could buy a commercial license to avoid this but if (for the sake of example) Azure's Mongo hosting was using the open source license would this mean that EVERYTHING that goes into Azure, down to Windows "Redstone" source code, would need to be released?
I think this is what a few of the "new" db companies thought the AGPL was (neo4j comes to mind).
Not simply "if you write a new query parser and link it into our db, any SaaS customers must get the modifications so the can continue running the service for themselves if you go under.", but more "if manage to extract value by hosting this software, you must give us a cut or all your code".
I guess there'll be a fork, like with matiadb/mysql?
(Context: I worked on Compose/MongoHQ for a very long time. We were the first to monetize MongoDB)
I'm sure people will get riled up about this, but it makes sense. Building a business on an OSS database in a world of behemoth cloud providers is really hard. It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind.
These things are going to keep happening as long as mega tech companies (a) use OSS to commoditize other companies' products and (b) exploit permissive licenses to the max.
I don't want to live in a world where the only infrastructure software we have access to is what the big companies deign to open source. Life is better when small groups of devs can build and sustain critical infrastructure software. We need more haproxies and redises and binds and (fill in blank).
That said, MongoDB has never figured out how to work with their ecosystem in a way that's good for everyone. They've gone from trying to extort money from smaller companies to undercutting them to this. And it's likely not gonna change much this time, the world of "run a database as a service" is changing I think, and being replaced with more generic tools that just so happen to manage complex persistence well.
_Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
> It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind.
Have you seen the degree of investment Microsoft has made lately in Open Source? It's an upside-down world where Microsoft if a bigger champion -- and funder -- of open source than a company like Google which was built on Open Source software.
But the companies that shepherd and develop the open source software and let the community use it for free has to be supported somehow. So unless the cloud companies want to fund these companies and thereby fund the developers of the open source software directly then these kinds of licenses make sense.
To put that $180B in perspective, the TOTAL revenue of the public OSS companies (or those that were public recently before being acquired) is roughly $5B. That includes Red Hat, Mongo, Cloudera, Hortonworks, Elastic, and Mulesoft. If 2/3 of a $180B market is driven by open source, and we want the cycle of innovation to continue, it's in everyone's best interest to find ways to connect open source cloud usage to direct open source monetization.
Google has released roughly every meaningful patch it has made to the open source software it was built on[1].
As for funding, that's definitely not true by the numbers last i looked (and definitely was not true in the past).
Without concrete disagreements, this is just handwaving.
So if you make some, i'm happy to argue with real data.
[1] The only cases i can think of that this isn't true is when the Googler who worked on it left before they got a chance to do that (and nobody has picked it up since)
Google has released roughly every meaningful patch it has made to the open source software it was built on.
Chrome or Android seem like good counterexamples, where the software that most people use (Chrome, or Android + Google Experience) is specifically kept in two separate buckets, open source and closed source, so that Google can strategically keep some parts open and some parts closed.
Err?
They are certainly not useful counterexamples. That is open source software Google made itself.
The original complaint was about taking other people's open source (mongodb) without contributing back.
Not "failing to release stuff it made itself". That's a completely different thing.
Even there, what i said is still true:
Google has released every meaningful patch to the open source software it used in making Chrome/Android.
For production server kernel:
The only kernel patches these days i'm aware of that aren't upstream are hardware drivers for very custom hardware, or ones we released but upstream didn't want and we still maintain.
Like any sane kernel team, google tries to minimize it's difference with upstream since it has huge maintenance cost.
Amazon also spends a lot of time and effort on Open Source software, including the Linux kernel. They also contribute money to various open source foundations and target funding for various groups like OpenSSL.
Microsoft gets all the news because it's a drastic change from normal behaviour.
Amazon, Google, Oracle et all just keep steadily contributing stuff. A lot of the work is also deadly boring and not headline capturing stuff.
Few simple queries to show the work they're doing just on the kernel:
I feel like many people deciding to use an open source license for their project never consider the consequences of such choice. They use OSS because it's "cool" or they hope to get some free work done for them. If you pick an open source license and someone uses your code to build something else within the license boundaries, that is not a Bad Thing(tm).
I have released many open source projects under MIT and GPL licenses and I have no problem with anyone repackaging it however they please, as long as they respect the license terms.
On the other hand, when I pick an OSS software to build upon, I pick it exactly because of the license and plan to use the license to the extent it is allowed. If the license doesn't look like a good fit, I use something else or write my own code.
I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
I just wanted to point out that from an Economic perspective this:
> I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
And the ability to utilize that war chest to cannibalize the best of open source to create private differentiators raises the barrier of entry for competition. This market would naturally drift towards an oligopoly-like market equilibrium.
Like I said, I agree with your perspective on licenses. I would just also like OSS to be the great equalizer that instills innovation and disruption in the greater tech market place. But so long as tech giants can take any good new OSS, pay top dollar to recruit great engineers, and then throw them at OSS then I don't think this ideal vision will come to fruition.
Ill add patent trolling and copyright issues like API ruling to what you said. The companies with money can pay bribes to weaken or block FOSS activity in varios ways. Better if OSS/FOSS companies have business models with money to fight that.
> I feel like many people deciding to use an open source license for their project never consider the consequences of such choice
I might say instead that the norms of open source software development -- attribution, collaboration, good faith -- are so baked in to small, high-trust communities that they might seem as though they'll be obvious to everyone. And then your software makes it way to the public and you realize that those were just assumptions and not written into the letter of agreement at any point.
The APGL exists for a reason. If that's the kind of development model you want, but then you instead pick a super permissive license like BSD/MIT, then that's on you.
And I say this as someone who has released all of his software within the past decade using either GPLv3 or APGL, for exactly this reason.
Companies receive a lot from society: technology, employees, customers, physical safety... and sometimes free work in terms of FLOSS.
When they fail to give back by dodging taxes, paying minimum wages, spying on people, cornering markets, competing against FLOSS project/orgs they are breaking good faith relations (and the spirit of law)
My personal idea is that you shouldn't open source anything you plan to make money from. Technologies that you build along the way (like React out of Facebook and a million other examples) are good candidates for open source.
Open source db software is suitable for these dual licenses - using it is free, but if you are going to sell products and services that are repackaged versions of the tool, you should pay the creator (like mysql).
"I'm sure people will get riled up about this, but it makes sense. Building a business on an OSS database in a world of behemoth cloud providers is really hard. It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind. "
This is simply not true in any meaningful way. Please cite real data. It's very hard to disagree with handwaving like this.
Both Google's official policy (which is super clear about this: https://opensource.google.com/docs/), and practice (releasing and working on tens of thousands of open source projects) say otherwise.
I would love to see the data that goes with this claim.
It seems like even if the cloud providers contributed 100% of their code back to Mongo it still wouldn't be enough to keep Mongo alive. They need money, not code. That's the subtext to this whole discussion.
AGPL was a roundabout way of hinting that cloud providers should kick back some revenue and now that it didn't work the truth can come out.
> AGPL was a roundabout way of hinting that cloud providers should kick back some revenue and now that it didn't work the truth can come out.
How does AGPL force kicking back of revenue? The only way I can think of is if the cloud-provider choose to relicense the software (for a fee), because they can always fulfill the terms of the AGPL by publishing all their changes without paying a dime.
There was an unstated assumption that hosting providers aren't willing to contribute back their secret sauce changes so they would have to buy a commercial license. But that didn't work. I don't know if the new MongoDB license will work either; the Commons "Clause" seems more honest in its wording.
Of course it's true. Google doesn't pay companies that developed open source software that Google now relies on. That's exactly how open source works. Google helps "open source" in general by releasing and funding open source projects. But Google doesn't pay companies that build useful open source software in the first place, to use their software.
My belief is: Amazon/Google (and to a lesser extent, Azure) capture a tremendous amount of revenue by coupling known OSS infrastructure with a hosted cloud business. This is because they've been able to extend unrelated monopolies
What you're saying is (I think): Google contributes code + projects back to the OSS community and sponsors OSS organizations.
I think if we could see the actual numbers — if it were possible to see Google's cloud revenue with associated OSS contributions — we'd see that what they're actually giving "back" is tiny, and it's the equivalent of donating to charities.
Assuming Google pays ~$250k salaries to all of those folks to work full time on other peoples' projects, they're spending about $500mm/year on OSS while making ~$2bn/yr on just Google cloud. And that's horribly optimistic, I doubt much of that money is going to projects Google doesn't control.
Google's original OSS projects are different, I tend to like them. But given Google's market power the actual effect is to commoditize all the things Google doesn't expect to make money on. Kubernetes is great. Mesosphere is increasingly irrelevant because of it. OSS projects from megacorps tend to have the same effect as price dumping. They can afford to spend more money making something an non-viable business than most companies can spend at all.
> comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind
Well, that's one way to put it I guess. I personally am OK with anyone taking my work and doing a ton of proprietary development on it. I wouldn't put it out there that way if I wasn't (and don't w/ my proprietary stuff).
We need to stop demonizing restrictionless development. Same with commercial/copy-left development of course, but I'm seeing too much copy-left righteousness these days. To each their own. Also, we need to stop being so prideful in our work that we consider some uses of it an affront. Sometimes when you make things available to the world at large sans restrictions you have misusers. That's ok. But hating the proverbial man tends to only negatively affect downstream users at large. MongoDB can do what it wants, and should commercialize where it wants, but all this corporate hatred coupled with openness righteousness should stop being used as justification.
> _Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
So are their customers and all users who lost some freedoms today because of perceived self-righteousness. Ashamed is a fair word for grinning after pivots like these, but I definitely don't see a problem with the pivot itself. Again, to each their own.
> Same with commercial/copy-left development of course, but I'm seeing too much copy-left righteousness these days.
I'm not sure what planet you live on, but the GPL and other various copy-left licenses have been on the slow decline for years in part due to things like SaaS negating the use of everything but the Affero GPL and the social 'implications' of using the GPL ("poisonous", "viral"), while the use of extremely liberally-licensed, "corporate-friendly" permissive licenses has skyrocketed.
You don't have to look far (I've seen it more than once) to find people submitting issues on places like GitHub to completely relicense a project, just because it was GPL. Even here, every time a piece of code with a GPL license is attached and posted, you can be certain of someone pointing this out.
There are technical factors involved (like what's the deal with JavaScript licensing), but ultimately less projects choose the GPL -- or any other "demanding" copy-left license -- than ever before, so I have no idea what you're talking about, other than a perceived persecution complex where you think people are trying to "stop you" from using their code?
Of course, the funny thing is you say we need to stop "demonizing" restrictionless development, and of all copyleft licenses, the Affero GPL actually has risen in usage. But that's not because there's a big mean group of copy-leftists making people do it through blackmail. It's because it's risen in usage in corporate-sponsored, open-core projects, precisely to disincentivize systems like large, already-rich SaaS companies sucking the money out of their core customers by requiring them to share the source code for their changes (which they are often unable to do, making it effective). Corporations that sell open source software exactly understand how this game works -- they don't want other companies directly eating away the bulk of their revenue streams by just slapping a stupid UX and some user management patches on top, and so they license their software in an appropriate manner to try to cover all bases (source available, but without already-geared-up companies eating away their direct lifelines).
You'll also notice most of the companies doing this strategy aren't already highly-powerful, highly-monied SaaS companies. They're often much smaller and starting off, trying to get their software in the hands of users, while retaining revenue leads. Highly powerful companies like Google can afford to just release everything under non-copyleft licenses like Apache or MIT. They can subsidize the development of the software through established business.
But I imagine most people on this website wouldn't see these companies as being "copy-left righteous", only "protecting their investment". Unsurprisingly, this kind of understanding doesn't seem to extend to individual developers who license their code under a copyleft licenses (who are "righteous", and have no reason to care about anything other than the most people possible using their software).
Maybe the "copy-left" righteousness you're seeing isn't a massive proliferation of copy-left licensing, but actually a result of people getting wise to the way this conversation plays out. After all, if I'm going to be accused of being righteous, I might as well use the GPL, since apparently anything less than a free-for-all isn't acceptable to a lot of people.
> I'm not sure what planet you live on, but the GPL and other various copy-left licenses have been on the slow decline for years
The planet that recognizes that proclaimed righteousness (what I wrote about) has nothing to do with adoption (what you wrote about). If anything it makes the righteousness stick out because it goes against what people are choosing. I rarely see GPL devs demonized for how they choose to give their code away, or blog posts and evangelists espousing anti-GPL, or the straggling person "eventually coming out and calling it poisonous", or justifications on non-GPL changes as claiming corporate harm.
I have no statement on license prevalence and it is unrelated to my comment. My statement is about justification used and being overly prideful of their work. Change and be done. One way is not necessarily better than another, and companies are not all bad, and that's not only who you are hurting with these changes, etc. But when I hear complaints about the company using up all their hard work like it's some zero-sum coffer being depleted, I don't pity them. I know the intent is guilt and I don't think it's a good look.
I don't see much in your argument apart from: I'm okay with this; you shouldn't be self-righteous; don't hate on corporations. Lots of telling me what I should do and how I ought to feel about my work, nothing really backing it up. In which case, I feel justified in simply responding: no, my values are different from yours.
It was more about what you shouldn't do, i.e. guilting others and how they use the software you made available. The values can be different, but that blame is not on someone else.
> We need to stop demonizing restrictionless development.
I'm not! I love permissive OSS licenses, I think they're great until they get abused.
What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
This license from MongoDB is an unfortunate side effect of that. I don't think anyone there wanted a weirdly restrictive license, but I do think they want to build a healthy business on top of their work. And that's something I want them to be able to do as well.
There's a big, big difference between companies in an oligopoly position and normal companies. Permissive OSS grew up in a world that wasn't a weird oligopoly for good reasons, but a lot has changed in the last 10 years and it's downright dangerous to license things permissively and try to build a business at the same time.
Example: we built an Edge Runtime, it's under a permissive license, if we're successful I expect we'll run into the same problem DB companies have and then have to navigate around that: https://github.com/superfly/fly
I think they're great even when they get "abused" (for that definition of "abuse" which I don't agree with).
> What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
Whether or not that is a problem is a different discussion, but suffice to say the license change will not solve or change that. It is naive to think so.
> it's downright dangerous to license things permissively and try to build a business at the same time
Well, if you attempt to build a business on the permissively licensed thing, of course. I'm not sure I concede that building a business on permissively licensed thing, thereby changing its license, is required. Building a business around it? Developing it with funds acquired on other business? Remaining small and not growing it beyond its original development? All of these are sustainable development models too. Before being so quick to blame these "megacorps" like they did something wrong, consider whether the changes to correct this "wrong" even accomplish the goal and whether that goal has any value of being accomplished. The intent of the license change has less value than its practical effect, and the idealistic way we'd like open source to sustain itself and be profitable is not always the pragmatic one. Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
I'm not sure what you think I'm arguing, but I also don't think the license change will solve problems for MongoDB. That they had to change their licensing so drastically is a symptom of a much larger problem.
> Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
They _are_ megacorps. It's ok to be fine with megacorps, but it's a little silly to pretend they're not.
They are a problem (you can disagree with this). We'd be better off with 20 smaller companies than one large Google. More innovation, less barriers to competing, etc, etc. It's not really righteousness, righteousness is more a moral stance than an "oh shit this is a bad state we're in".
It's funny because redis recently did something rather similar to what mongo just did. This will be an accelerating trend in open source, where these sorts of companies will either develop proprietary platforms with closed source code (databricks), or will move forward the way redis and mongo are.
> This will be an accelerating trend in open source
Until communities refuse to sign CLA that let projects bait-and-switch to another license once they have a large community and want to now take buckets of VC money.
In my experience its the opposite. Companies form around the business plan of exploiting FOSS by hosting, solicit buckets of VC money, and give nothing back. It's completely unsustainable.
It's totally rational to create a license model that prevents hosting to third parties, but still allows end users to adopt the technology without paying. As has been pointed out elsewhere, that may not be right for all OS projects, but it should be an option.
There's no issue here. The whole point of OSS is that anyone can use it. Cloud vendors are providing managed services because that's what their customers demand, and the value isn't in the software itself but the managed part of it all.
Any other company (like Compose) can do the same thing and there are several hundred vendors offering various options. MongoDB Atlas is entirely this, and seems to be doing well by leveraging their own expertise and moving faster than the others.
If MongoDB now wants to change the license then they're free to do so, but they'll face the consequences of becoming more proprietary with their offering. It may help or it may hurt, but there's not some big universal argument to be made. If you don't want to make and give away free stuff, then don't. The rest of the world will still manage just fine.
You've got it backwards. The fact that we now have cloud providers is a direct consequence of F/OSS and the software commoditization it brings. Cloud (running other people's software) and support are the only ways to make money in this market, so I'm expecting lots of fighting, cloud-specific forking, and license changes going forward. Cloud providers don't manage shit; they're just employing bottom-of-the-barrel staff to kindof keep things running, and put just enough development effort into their cloud offering to lock you in to their walled garden.
What's backwards? Who cares how we got cloud providers? They are responding to customer demand and we've had colos and datacenter players for decades doing similar things, just at a smaller scale.
Obviously the service is managed and that has value, regardless of the backend and your opinions on how they run it. Perhaps your issue is with all the customers who want and pay for this rather than providers meeting a need.
Yeah sorry reading my post just now I should've edited it, or not submitted in the first place. What I meant is that F/OSS has kindof created a situation where no commercial software development by ISVs is sustainable, and now F/OSS itself looses one of the last remaing avenues for monetarization eg. feedback into development and innovation.
Why does this debate consyantly flare up again and again? No one is exploiting licenses, if you release something as open source then it’s open source, amongst other things you give up any claim to the money others might make using your software. That is your choice, any no one is exploiting you or your work by using the software within the license you granted them.
People need to stop this attempt at having “financially closed” open source. If you want you software to be propriataty and have limitations on usage just do that. Don’t release it as open source and cry fowl when other treat it like that instead of treating it like you had a proprietary license on it.
This license seems to insure that MongoDB Inc either gets all source code to Mongo-as-a-Service from their competitors (which they can use to make a better service themselves) or they make money from all of their competitors through commercial licensing. Perhaps Oracle is preparing to acquire MongoDB Inc and this move is a prerequisite to acquisition?
I hope OSI and the FSF don’t approve their new “SSPL” license.
AGPL style licenses impose restrictions on usage, thus violating freedom 0 in the Free Software’s definition or Open Source’s rule 6.
AGPL should have never been allowed, precisely because it opens the door for commercial entities to eat their cake and have it too, being the kind of license that can be effectively used to disallow commercial products built on top.
In my opinion your own modifications that are never distributed (by the copyright definition) represents mere usage. And we’re software developers after all, personally I patch most of the libraries I end up using and some patches I may contribute back, but I’m definitely not required by any license.
“Open Source” and “Free Software” have great sex appeal, I get it, but if you can’t deal with competitors benefiting from your work, which is the whole point of such an endeavor, then don’t do FOSS.
Yeah, I agree it is not an open source license based on rule 9 alone. I mean, the reason for the license not being open source is not an accident. It's not some unforeseen side effect. Their whole purpose of changing the license is to restrict the freedoms of the service companies using the software. I'm somewhat sympathetic to MongoDB for wanting to extract money from them or to force them to work with the open source community. However, you can't have your cake and eat it too. Forcing them that means your license is not open source.
Completely disagree. How does AGPL interfere with your ability to run a program? I can clone any AGPL software and run it for whatever purposes I want. It also doesn't discriminate against any field of endeavor. I can run AGPL software and charge for it. "Distribution" has changed since 1991 and AGPL extends the viral qualities of GPL to apply to internet services, which is a Good Thing for free software.
> AGPL style licenses impose restrictions on usage
No, not in the commonly understood sense of "usage" as "field of endeavor". I understand what you're getting at but anybody can use AGPL'd software for anything. They just need to publish any modifications they make to said AGPL'd software. It's a restriction, but not on "usage". Such a restriction would be something like "you can't use this in the nuclear industry" or "you can't sell this".
For me usage is the ability to modify it for my purposes.
Writing a script that interacts with said software to enhance or modify its behavior is as easy as clicking an UI button and I don't see a difference.
Also the "understood sense" is irrelevant. Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
The genius of the GPL licenses has been that they are just copyright licenses handling distribution, but that don't impose any restriction on usage. This was by design. Here's Richard Stallman's own take on "freedom 0": https://www.gnu.org/philosophy/programs-must-not-limit-freed...
> "They just need to publish any modifications they make to said AGPL'd software"
N.B. that's in fact a huge restriction, being a matter of costs too, because "publishing any modifications" costs both time and money.
You can still modify it for my purposes so long all users who interacts with it over a network has access to the modified source code. If the number of users are you then modify away!
> Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
That is the tricky part. A video streaming site is considered distribution by many copyright laws. There was a time where simply using a website was not considered distribution, but then scope of copyright was extended and concepts like "public performance" and "making available to the public" was applied to works provided through web services.
GPLv3 however gives an additional permission that allow "interaction with a user through a computer network", even if copyright law would forbid it.
Personally I agree with copyleft licenses for as long as they are just restricting distribution as defined by copyright law. This because IMO there needs to be a clear, lawful boundary for what FOSS licenses can and cannot restrict.
Why would we want to force a company like Mango to go proprietary? There is a virtuous cycle at work when companies build business models that enable them to stick around and continue to make significant community contributions as Mango has done. The cloud has enabled bad actors to cut off the air supply of contributors. If you care about open source, you should care about the ability for companies to build business models around it that are benevolent to individual users, but don't let parasites suck the life blood out of contributing organizations.
I personally see why MongoDB switches its license and clarify their original intention of using AGPL.
I even didn't know it was AGPL until now (I'm not MongoDB user). Because so many people seem to use it as if it is Apache License or something free of charge. I haven't see any warnings on AGPL and its implications in MongoDB tutorials on the internet.
The drivers are all permissive OSS licenses. It's on purpose, they never wanted to own applications that are built on top of MongoDB, but they never wanted to give away the server bit either.
I meant people seem to install the server too, thinking that the server itself it free. Most of MongoDB tutorials on the internet starts with "how to install locally" without mentioning nothing about the license.
The server _is_ free. As long as you don't modify the server, you don't have any obligations. If you do modify the server, you're only obligated to publish the changes you made to the server. No one is at risk of violating the license by installing it locally and using it in an application.
They are hurting their own ecosystem, trying to get more money. Not a real open source project, just proprietary software mimicking open source. Compare to PostgreSQL, it's absurd to think that they would forbid using PostgreSQL as a service.
My biggest problem with this is just that it contributes to "license proliferation" even if OSI certifies it. It muddies the waters and makes OSS licensing that much more confusing. In this regard, I'm fairly leery of it.
As for what they're trying to accomplish... it sounds like a slightly different version of the AGPL (in spirit), and while I'm not the biggest fan of the AGPL and similar licenses, it's not the abomination that the Common Clause stuff was. This seems to just be saying "if you want to offer a MDaaS (MongoDb as a Service), you have to release the source code to the entire service". It's probably not a license I'd choose, but it's not exactly unreasonable.
Disclaimer: I haven't read the entire license yet, so my comments above are based on other people's summaries / the text of the article linked above. My opinion is subject to change once I've had time to digest this fully.
What really should happen is that the large cloud companies (really just Google, Amazon, and Azure) should be providing a portion of the revenue generated to the open source projects. The open source companies would make more features and drive more usage. Everybody wins. It makes no sense that the large cloud providers make billions off OSS, and don't give something more sustainable back. Classic tragedy of the commons.
Disclaimer: My company Storj is building a distributed Amazon S3 competitor and we are actually partnered with MongoDB. We share revenue with MongoDB for any customers they bring us.
The author or company building the software requires money in exchange for using their software. The revenue acquired through the license is then use to pay for additional development.
Revenue sharing seems to imply some kindness / goodwill agreement.
Your 3 examples have a LOT of swes that work full time on open source/cncf projects not to mention they're platinum members of CNCF/Linux Foundation, etc. So I think that's a bit disingenuous. They're not funnelling billions into those tunnels but a huge majority of contributors are Redhat, Google, Coreos, Huawei, Alibaba, Intel and various other big names that definitely use open source tech and provide a huge benefit to us that are consuming it. K8s is moving so fast it's hard to even follow.
Kubernetes was donated to CNCF and there are a lot of Google SWEs working on "removing Google" from the actual project to make it more cloud native.
I really have a hard time picturing the success of CNCF/etc without the big names.
From a global perspective it looks pretty fair that some company uses a lot of open source software and also contributes a lot. But it doesn't get anyone paid. If you're toiling away unpaid on Redis or MongoDB or whatever, the fact that Google gave the world k8s does not help you.
> the fact that Google gave the world k8s does not help you.
so google should give everything away AND also need to pay to every open source project, besides that smaller player don't?
sorry the world does not work like that.
open source means giving and taking, not only taking.
google might not be an angel, however restricting them to pay - OPEN SOURCE, non restrictive work - is just silly.
I’d hazard a guess that even the most prolific open source individual contributors use more open source software written by others than they contribute to.
Nobody individually, could really ‘pull their weight’ with respect to contributing back to the community. I doubt most corporations could feasibly contribute back more software than they use, even if they tried.
How much of the money donated to organizations like CNCF or the Linux Foundation goes to the individual contributors who build these products?
They do help in some respects: I don't think Kubernetes would be as successful were it not for the big conferences put on by the CNCF. And, of course, lots of companies actually are contributing code back to Kubernetes particularly (and Linux, and some other projects). But there are also a lot of popular open source projects which are used by lots of big companies but don't get either code or money from them.
I'm looking forward to trialing the Storj product. Did you use something like http://outwork.com to setup the deal? How does a partnership like that formulate?
People weren't "testing the boundaries" of AGPL. You need to know nearly nothing about AGPL to understand this. The bottom line is, AGPL merely requires you to publish your modifications. But if cloud providers are offering essentially a vanilla MongoDB instance, there is no reason they are compelled to buy a commercial license.
Still, I wonder where MongoDB actually wants the boundary drawn. Anyone that tries to offer the MongoDB protocol as a service using the official code? Or is it if I provide a database interface to a MongoDB instance? Or is it only if the actual MongoDB interface from the MongoDB server is provided? I haven't read their new license but I have a strong feeling that it won't be 100% clear yet.
This would be futile. The forks could still implement the protocol changes as long as they didn't take code from upsteam to do so.
I believe there is also case law that supports the legality of reverse engineering for interoperabilility as well. I wonder if that has implications on this.
I don't think this really changes anything with MongoDB and how open or closed it is in practice. This really is just MongoDB clarifying their original intent with picking the AGPL. Basically, if you're going to offer MongoDB as a service, you either need to make all your service's code freely available, or you need a commercial relationship with MongoDB. This doesn't change anything for users of the software that are building applications.
This is just another highlight of the cloud vendors making it very difficult to build a business based on open source infrastructure software. Either you pick an infectious license (like AGPL) or you go open core. Otherwise, if your project gets popular, the cloud providers will offer it as a service, which will eat into your revenue.
Alibaba & Tencent have been offering managed MongoDB offerings for a while but MongoDB, Inc. has historically not made any major investment in its own managed offering (Atlas) for that market.
This license shift is aimed squarely at AWS, who is rumored to be ready to announce/release their own MongoDB-compatible service at AWS re:Invent next month.
Is there an OSS license where it won’t allow other providers to offer the original technology as a service and charge for it?
If I want to use MongoDB in my ecommerce app no worries. If I want to simply use MongoDB offer some minimal improvement or added functionality, call it ZongoDB and sell subscriptions... not so fine?
Is there an OSS license where it won’t allow other providers to offer the original technology as a service and charge for it?
No, because such a license would - by definition - not be an Open Source license. That's basically what the Common Clause says, but a license with that clause attached isn't OSS.
(With the caveat that I think what really matters here is "and hoard changes and updates", not "make money at all":) The AGPL comes to mind, but I bet that is slightly too viral? It is a hard problem: how do you legally differentiate a web app built on top of MongoDB from a thin wrapper for MongoDB that provides a minority different API from the backend (or might even simply be a load balancer)?
"Software as a service" is a well understood concept, and on the strength of that understanding, the SSPL is clear. (Although as with all things there are edge cases, there aren't more edge cases with the SSPL than with other licenses.)
If your web app uses MongoDB (or any SSPL licensed software) to provide a value that is not substantially MongoDB itself, you are not making the software available as a service. If your code facilitates making MongoDB's features available to other users, you are providing MongoDB as a service and are obligated to make all that code available under the SSPL.
> Is there an OSS license where it won’t allow other providers to offer the original technology as a service and charge for it?
No. Open Source always implies freedom to use for any purpose. There might strings attached such as the need to open-source modifications as well, but if usage itself isn't free, it's not Open Source.
No. Restricting commercial usage or selling it is against the ethos of free and open source licenses. The Open Source Definition has a rule stating a license must not discriminate on fields of endeavor and the FSF has been pro-selling free software since its inception (it's how RMS made money in the early days of GNU and how the FSF funded itself for a long time)
It's interesting, because it seems they're making an even stronger license, requiring source to be available over a network for download - it seems they could have left that paragraph in.
Yes this is even more restrictive than GNU AGPLv3. If FSF is ok with these changes they might even approve it (GNU AGPLv4? Recall that AGPL wasn't a thing before Affero made it).
Everyone is
permitted
to copy and distribute verbatim copies of this license document, but
changing it is not allowed.
Can someone enlighten me on the significance of this piece of text? Does it mean you're not allowed to edit the license and publish it under the same name, or does it effectively copyright the entire license text? I'm gravitating towards the former since this is a case where the text was edited but renamed, but I'd still like some clarity.
As an aside, is it even possible to copyright a license? There's a copyright notice so isn't this technically plagiarism?
486 comments
[ 2.4 ms ] story [ 514 ms ] threadBut, it feels like yet another fallacy. What really is an open source project then?
Say some developer X contributes to a project like MongoDB his/her open source code so that they can one day run MongoDB as a service and make money. At that time, he/she believe that status is true and submits their code. But, later, after the project is mature, the major contributor easily changes license at will, and the open source contributors walk away with nothing?
I'm not saying that MongoDB Inc, does not have the majority stake here. Just wondering about whether it is a "bait & switch"esque move?
Imagine if all projects did the same... Say Docker? later on chooses to say that you can use Docker for free but if you distribute your software through repositories supported by the daemon, then you need to pay up.. Wouldnt that be a loss for the contributors that are not working for the company?
Amazon can afford to fork the project and poach top talent from your company. I think these moves are extremely short-sighted.
Changing license models only causes instability in the overall ecosystem.
Amazon employee here. Amazon offers two different types of service. For a service like Amazon RDS then yes it is the standard open source project hosted and managed by AWS. The value add is that you don't have to administrate and back it up, etc.
For something like Amazon Aurora its a different story. Aurora is API compatible with MySQL and Postgres but it is designed internally to work quite differently, really designed for the cloud first. And the result is its up to 5x faster than the standard open source software and just better than the open source version in many ways.
Both as a former customer of AWS and now as an engineer at AWS I have always preferred the from scratch implementations by AWS over the hosted open source versions. I'd rather not use a forked version of open source. I'd rather use something built by AWS engineers from the ground up
It's also noticably slower than plain PG in other cases.
For the record: I'm not a big fan of Mongo (the DB) but I think MongoDB, Inc. raises a valid point wrt. developers doing all the hard work including community building and a million other things, while "cloud providers" get all the money. This isn't sustainable, and we need a license which more clearly says "if you make money with it, you need to give us some", rather than using the bare AGPL license without further qualifications in the hope AGPL's "freedom" aspirations have the indirect effect of forcing commercial users and/or resellers to pay.
The projects you mention: Linux+git development has good financial standing from companies who could be seen as going (or having gone) aggressively against commercial Unix from a business PoV. gcc thrived on freedom enthusiasm but has seen many, many patches from commercial vendors wanting their OS, CPU or whatever supported.
How much AWS shares its profits with GCC, qemu, etc? Not at all besides the bare minimum that benefits them.
(And don't misunderstand me, I don't see Mongo as some kind of underdog here, but making big money from software is hard, even if - or exactly because - valuations - and funding - are in the sky.
And AWS is fundamentally a different kind of business than what open source usually is. It has a compounded networks effects / economies of scale effects. And on top of that it has a closed source management layer, but that is largely irrelevant, except for Mongo in this case.)
Linux, gcc, git OSS projects are less concerned about capturing value from the economic activities enabled by them, which is why they were all set up as not-for-profit enterprises; the expectation is that donations will help cover their operating costs.
MongoDB on the other hand is a for-profit enterprise that took VC funding in the hope that they'd be able to cover their operating costs in the long term without donations.
The only way to do this is to capture some of the value offered by the NOSQL paradigm, but it appears that the cloud providers are beating them at that game, which is why they needed to change tactics, to guarantee their survival as a self-sustaining entity.
I think MongoDB is free loading off the the community and developers. The developers don't get to use the software to make a profit without kicking some money upstream to mongo either. Is Mongo going to start offering money for bug reports and patches or do they get to freeload off of their community?
[1] https://azure.microsoft.com/en-us/blog/azure-cosmos-db-micro...
IMO, Azure remains a garbage fire of half-finished features in almost every offering. We replaced Cosmos with a Bitnami-authored canned VMs pre-configured for a simple Mongo cluster (which make up a significant portion of "features" they offer), which failed to restart after the Meltdown cloud reboot because the Bitnami management software corrupted the disks. Now we just run our own VMs with our own Mongo instances and curse the day we were obligated to move to Azure.
[0] https://feedback.azure.com/forums/263030-azure-cosmos-db/sug...
Of course that would be pointless as anyone who forked before the license change could continue re-distributing under AGPLv3.
_minified_ shell scripts
I'm not sure how these ideas tie together.
This is self evident from the licences themselves but also clearly reasonable if you consider the proportions of contributions made. Why should a contributor get rights to all future work on a project made primarily by others solely by making a contribution?
> ...and the open source contributors walk away with nothing?
Nope. As others have pointed out, they walk away with the Free Software licensed version of the code to which they contributed, together with their contributions. This code base does exactly what it did at the time of their contributions.
Wait just one second here. Is docker still open source or is Moby the new open source docker?
https://blog.docker.com/2017/04/introducing-the-moby-project...
My understanding is that recent versions of docker is indeed not open source but moby is? Is that correct according to the OSI?
1. You’re still helping education, nonprofits, and individuals benefit from your work.
2. It’s still open source, so people will still be able to contribute and use your work in their own projects.
3. Companies that want to use your code to make money can do so, but only if they also help out the other “worthy” causes by contributing changes back.
In fact, I'm consider something more radical like a YUMMY license (you make money, I make money) - which has all the same benefits of being open source and helping worthy causes, except at least you get to make money when someone uses your work to do something that you might not even want, like selling ads.
Small developers and companies without layers of lawyers will read the licence, see that it says "do what the ---- you want", and use your code accordingly.
Big companies with layers of lawyers will read the licence, blanch in terror, and either refuse to use the software, or contact you for alternative terms.
Case in point: Google forbids use of the WTFPL. https://opensource.google.com/docs/thirdparty/licenses/#wtfp...
We go over it in new googler training (and our reasoning is on the Google open source policy site we publish: https://opensource.google.com/docs/thirdparty/licenses/#wtfp...)
You are welcome to not (but if you go and look, it's completely consistent with my viewpoints and history in OSS so ...).
I would love to live in a world where WTFPL is a good license, but we don't live in that world, and wanting it to be so will not change that.
I can also tell you stories of companies we've acquired who had bad experiences, FWIW.
So the "small companies" you think are being served, aren't.
You clearly didn't read the link i said which says our issue with WTFPL is with the lack of warranty disclaimer and with the rights grant (which is not likely to be valid in a number of countries).
You will find nothing, nor have i stated anything about the ability for google to use the code for "monetization" reasons. It doesn't even enter the equation
It is very hard to take your comment in good faith as a result.
Our policy pages are clear on why we ban licenses, even things like AGPL. You'll note they are not economic concerns (IE google won't be able to monetize), but compliance ones.
(Of course, you should view these in good faith, they were originally written for an internal audience)
I can definitively state I have never banned a license at Google due to Google's ability to "monetize" the code, or even indirect versions of that (IE that if it became popular, it would hurt google's ability to do that). All concerns are compliance ones.
Additionally, the pages i linked you to very clearly encourage people to contribute back as much as they can.
AGPL compliance wouldn't be that difficult if you remove making money from the equation. So indirectly your compliance concerns are based on economic concerns.
This is simply false (on both points), and you haven't given any reason it would be true past "i feel this way". Even with direct support from our build system, AGPL compliance is incredibly difficult relative to GPL and other licenses[1]
This argument also amounts to "I know more about your job than you do", which, if you do, awesome!, please feel free to do it :) I'm actually happy to go do something else.
But i don't see evidence that this is true.
[1] For starters, we have to distinguish between what things , what are user facing, what kinds of users have access to them (IE internal services accessible only to FTE googlers are different from those accessible to TVC for AGPL purposes) , etc. This is an incredibly difficult set of problems on the technical side.
That is always true, even for non-open source licenses.
You could take MIT code and comply not just by publishing a notice but by publishing all of it. I don't think that is a meaningful argument against the annoyance of having to collate and publish notices.
Imagine if you have a commercial license that requires you be able to allow them to look through your books to verify software licensing, that often has high cost. Your suggestion is basically "why not just make your books public" (IE more than the contract requires). I don't think that's a meaningful argument against the cost of compliance, because that's not about compliance with this license, but instead one that requires more.
The whole point of contracts/licenses is that they are a deal. What you are suggesting is a very different deal, and we'd deal with it a very different way.
Please do, to the extent their experiences relate to informal licenses.
The lack of a warranty disclaimer isn't an issue in practice; my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law.
More important, to me, is what WTFPL says about my code: I'm not precious about it, I give it to you, I trust you to go do amazing things with it. It is a very humble licence. It says life is too short to get precious about licence wankery. Plus there's the side-effect that small companies and artisan developers can use it, while behemoths like Google won't. These, in my view, are all to the good.
I don't expect you to share that view, but for these reasons, WTFPL is a "good licence" for me. OpenStreetMap thrived for years with a WTFPL-licensed editor (I wrote/maintained it). No-one died, no-one got sued, and OSM became one of only four worldwide geodatabases. The main reason the current editing software isn't WTFPL (I started it but handed over to more talented developers pretty quickly) is that Intel wanted to use it, went "WTF WTFPL", and asked the new maintainer to change it. He did, but tagged the next release idiot-intel-lawyers. I laughed.
(IANAL, though I have spent way too much time over the past 15 years studying licenses and their applicability across different jurisdictions, again principally in connection with OSM and with its - very successful - licence change.)
There have in fact been developers sued (and they lost!) over this very issue in analogous situations, so i'm not sure why you say this.
"my readme just says "WTFPL, no warranty". The vague rights grant isn't something I've seen as an issue in analogous situations in case law."
I'm not sure where you looked. Judges have varied wildly in what they have done in analogous situations.
We are nothing if not data driven. If we didn't have very good data that suggests it is an issue, we wouldn't care.
> I'm consider something more radical like a YUMMY license (you make money, I make money)
There are some projects to create such a license like License Zero
https://licensezero.com/licenses
and there is some discussion on the P2P Foundation:
https://wiki.p2pfoundation.net/Copyfarleft
> It is exactly the same as (CC) non-commercial, except that commons-based commercial use //is// allowed.
Minor pet peeve, I understand that different people use open source differently -- but I would classify the license you're describing as source available. A FOSS compatible license can't carry restrictions on usage.
I'm assuming you already knew that and were just using the looser, more generic definition. Which is not a problem, I just have seen enough people get confused later on when somebody says, "well, technically, this isn't strictly Open Source", so I like to point it out for anyone else who's reading.
Instead of switching the license, they should have gone after companies that were abusing the terms of GNU AGPLv3 license.
There is literally no reason I’d use MongoDB anymore over any of its better FOSS competitors.
I've no idea if this is easy or not but it could be used as a negotiation tactic (I'm guessing here) to negotiate a license deal.
One irritating feature of Mongo (and I suppose other db's too; orientdb does this) is that once it grabs disk space, it never lets it go. It'll reuse that space, but the OS will never see it again. (EG: If I store 10GB of stuff, and delete 9GB of it, the OS still sees all 10GB of disk used).
Does rethink do this as well?
actual license: https://www.mongodb.com/licensing/server-side-public-license
Typically, TC didn’t bother to even link to either. :/
Doesn't AGPLv3 already require open sourcing server side implementations?
Thanks in advance
“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.”
^ not the same.
It's going to backfire hard when distros start removing Mongo from their main repos.
(Thanks for the explanation, "DFSG" passed over me the first time I read this. "Debian Free Software Guidelines".)
Since the new Mongo license violates rule 9 of the DFSG, it is considered proprietary software by Debian's definition, and that means Debian's FOSS policy will require Mongo to be moved out of the core repos and into the non-free repo. Fedora and Ubuntu have their own policies which will have the same effect.
Last week I was debating whether MongoDB is now completely obsoleted by PostgreSQL’s JSON datatype. As of now, I consider that no longer a debate.
No, I think the real goal here is to make it effectively impossible to use this in a business setting without buying a commercial license. I'm glad Linus and RMS didn't see it that way.
===
However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.
===
Not that this makes the issue any more clear or enforceable...
There was no abuse, there was only mongo not being able to make money in all cases they wanted to. That's what they see as abuse. It isn't.
While they complain of bad actors, bad actors always act bad. This will not disincentivize them (they are also often in a lot of interesting jurisdictions that would make it hard anyway).
Instead, this is really about making it completely unpalatable for normal actors to not pay mongo in every single case.
Otherwise, one has to believe that mongo is going to go off and sue a bunch of people now, which would be a horribly stupid business model.
Abuse is often legal.
This feels a lot like when i hear about "GPL" abuse when it was specifically not designed for what people think is abuse (and that's not my view but stallman's).
Similarly, AGPL was not designed to require every piece of software around a piece of AGPL software to be open sourced.
Deliberately so. Not doing so is not "abuse".
You may have different goals, and that's actually fine! But it doesn't make following the license and what it was meant for abuse.
I'll also point out: In the history of my work on open source, by far the largest legal abusers of open source are startups. By many orders of magnitude. This is real abuse in the sense of clear license non-compliance. I worked on M&A at a variety of companies that acquired all sorts of different kind/stages of startups.
They rarely are compliant with even simple notice licenses (IE don't bother to post notices), let alone any of the more restrictive licenses.
Large corps often have legal departments that try to understand and consider and figure out what to do, even if they do it wrong.
So to me, every time i hear "large company open source abusers" i kind of laugh, because IMHO getting the startups to stop abusing open source would have a much more significant difference on OSS than getting 2 or 3 large companies to stop "abusing" it.
It's situational, but if you define abuse as "breaking a contract or law" we're not going to agree on anything about this.
MongoDB has _always_ wanted to make money when other people make money reselling their work. The AGPL doesn't really do what they needed, but their intent has been clear since day one.
Give me concrete examples.
I explicitly pointed out to you a social norm, not a violation of contract. I did not define it as breaking a contract or law. I defined it in terms of the social norm that was set by the creator of the license, or the "spirit" of the license.
I want to understand what you see as "violation of that spirit", not the legal definition. As mentioned, most definitions i've seen here are explicitly not what the creator of the license intended (again, not what they wrote down, but what they intended). It's hard to see something that doesn't violate the spirit of the license as abuse.
For example, i often hear about "not contributing back" to GPL projects. RMS explicitly was okay with "not contributing back" in the broader sense, as long as they released their source code. He had no expectation he would get anything other than a pile of source that he would have to deal with. He just wanted to be able to hack it, so as long as it had the right stuff, he didn't expect others to care. He thought it would be nice for sure, but it's not "abuse".
(A great concrete example of abuse is usually binary kernel blobs that have deliberate shim interfaces. This clearly violates the spirit of the license even if the license says it may be okay.)
So far i haven't seen what you have defined as abuse especially by "large companies".
Additionally, I pointed out to you the notion that large corporations are the ones doing the abusing is wrong under almost all definitions of abuse, spirit, legal, aspirational, you name it.
Companies like Google, MS, Amazon are not violating norms but complying with them. When companies like MongoDB abandon these licenses its because they're incompatible with their business model.
Open Source is fine for them while they're making a market and developing a programmer user base, becoming popular with people who will not bother with a new proprietary database, mind you, but once they're 'popular' and need to increase revenue, the license gets replaced with a familiar , proprietary, one.
This is a bad analogy for software, since software is not a finite resource. Anyone can make a near infinite number of copies.
Don't blame 3rd parties when you realized that an open source license is the wrong license for your product.
I don't think this takes away from MongoDB picking the wrong license and business model.
Using your analogy, MongoDB is taking all of the free community that is around open source and changing the license after they have a community so they can extract/shakedown money from people. If anyone is abusive, it's people like MongoDB changing the license after they got lots of free contributors adding to mongodb.
The AGPL is just generally a ridiculously badly written license.
Some companies are illegally running a modified version of MongoDB while keeping their changes closed source.
As I understand, the new licence will allow them to do that if they pay a commercial licence (contributing to the project by financing instead of coding).
In the matter of allowing commercial licensing by the copyright-holder, the AGPL and this new license do not differ.
Yes this is not going to stop the Asian cloud providers they talk about. It is truly aimed at AWS et al. If they came out and said that it would not sound as nice. Mongo just made a big move in the cloud space by buying mLab. They are looking to contain the competition.
The cloud competitors MongoDB professes concern about have sophisticated software license counsel. They're very good at reading licenses. That is part of the claimed problem: They were good enough to see and exploit loopholes in a dense, oddly drafted license like AGPLv3, which most others read as "free for free software only", rather than as written. They also have deep pockets, US legal nexus, and significant ongoing commercial use to enjoin. The latter make a wide target. But the former makes them too strong to sue on anything but firm ground.
I don't know what you mean by normal actors, but if there are a lot of them, and they're relatively small, and also potential Mongo customers, suing them en mass to make examples, RIAA/MPAA-style, isn't nearly as appealing as cutting big cloud providers offering MongoDB off from updates with a license change. Everything about these changes and the materials accompanying points to the latter.
I don't see Mongo announcing any litigation campaign for going beyond AGPLv3 permission. I do see Mongo drawing a new line in the sand, via a new license for new releases, that will be easier to defend against the specific competitors they see pushing the limits of the old line.
Or they might just release their entire stack, which is probably 90% open source stuff with 10% glue code anyway.
There’s more to running a business than just cloning a software stack. Any idiot can fire up an OpenStack based ‘cloud’, but that won’t make them the next AWS.
https://blog.mlab.com/2018/10/mlab-is-becoming-a-part-of-mon...
Probably the big public cloud providers in China (Alibaba etc) as well.
Does that mean that MongoDB is now infringing on FSF copyright of the license text itself?
BTW, check out the "What specifically is different between the GPL and this new license and what will it be called?" section of the FAQ:
https://www.mongodb.com/licensing/server-side-public-license...
I don't see how the distinction makes a difference here, both have the same clause about changing not being allowed.
https://www.gnu.org/licenses/gpl-faq.en.html#ModifyGPL
From MongoDB, Inc's POV, its fine to run MongoDB in-house for the purposes of supporting some user-facing application. Coinbase would be a good example, they make a consumer product that uses MongoDB as the storage backend.
What is definitely not allowed is selling fully hosted MongoDB instances. E.g. (https://cloud.yandex.ru/docs/mdb/). To do this you will need to open-source all the supporting infra/automation code which will be a deal breaker in many cases.
The real grey area is a service like Parse or Firebase that is built on Mongo but offers a Mongo-like DBaaS. Is it against the SSPL to build a service like that? Or is MongoDB, Inc trying to force everyone to use its MongoDB Stitch service [0]?
[0] - https://www.mongodb.com/cloud/stitch
it isn't actually I guess google runs their RDS on kubernetes anyway.
Not simply "if you write a new query parser and link it into our db, any SaaS customers must get the modifications so the can continue running the service for themselves if you go under.", but more "if manage to extract value by hosting this software, you must give us a cut or all your code".
I guess there'll be a fork, like with matiadb/mysql?
I'm sure people will get riled up about this, but it makes sense. Building a business on an OSS database in a world of behemoth cloud providers is really hard. It's clear Google and Amazon (and maybe even Azure) are comfy taking OSS work, doing a ton of proprietary development on it, and leaving the companies who did all the groundwork flailing in the wind.
These things are going to keep happening as long as mega tech companies (a) use OSS to commoditize other companies' products and (b) exploit permissive licenses to the max.
I don't want to live in a world where the only infrastructure software we have access to is what the big companies deign to open source. Life is better when small groups of devs can build and sustain critical infrastructure software. We need more haproxies and redises and binds and (fill in blank).
That said, MongoDB has never figured out how to work with their ecosystem in a way that's good for everyone. They've gone from trying to extort money from smaller companies to undercutting them to this. And it's likely not gonna change much this time, the world of "run a database as a service" is changing I think, and being replaced with more generic tools that just so happen to manage complex persistence well.
_Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
Have you seen the degree of investment Microsoft has made lately in Open Source? It's an upside-down world where Microsoft if a bigger champion -- and funder -- of open source than a company like Google which was built on Open Source software.
Google has released roughly every meaningful patch it has made to the open source software it was built on[1].
As for funding, that's definitely not true by the numbers last i looked (and definitely was not true in the past).
Without concrete disagreements, this is just handwaving. So if you make some, i'm happy to argue with real data.
[1] The only cases i can think of that this isn't true is when the Googler who worked on it left before they got a chance to do that (and nobody has picked it up since)
Chrome or Android seem like good counterexamples, where the software that most people use (Chrome, or Android + Google Experience) is specifically kept in two separate buckets, open source and closed source, so that Google can strategically keep some parts open and some parts closed.
The original complaint was about taking other people's open source (mongodb) without contributing back. Not "failing to release stuff it made itself". That's a completely different thing.
Even there, what i said is still true: Google has released every meaningful patch to the open source software it used in making Chrome/Android.
Like any sane kernel team, google tries to minimize it's difference with upstream since it has huge maintenance cost.
Microsoft gets all the news because it's a drastic change from normal behaviour.
Amazon, Google, Oracle et all just keep steadily contributing stuff. A lot of the work is also deadly boring and not headline capturing stuff.
Few simple queries to show the work they're doing just on the kernel:
Amazon: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Google: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Microsoft: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Oracle: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
I feel like many people deciding to use an open source license for their project never consider the consequences of such choice. They use OSS because it's "cool" or they hope to get some free work done for them. If you pick an open source license and someone uses your code to build something else within the license boundaries, that is not a Bad Thing(tm).
I have released many open source projects under MIT and GPL licenses and I have no problem with anyone repackaging it however they please, as long as they respect the license terms.
On the other hand, when I pick an OSS software to build upon, I pick it exactly because of the license and plan to use the license to the extent it is allowed. If the license doesn't look like a good fit, I use something else or write my own code.
I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
I just wanted to point out that from an Economic perspective this:
> I don't feel like Google/Amazon/etc. owe anything to anyone just because they made it and now have a lot of money.
And the ability to utilize that war chest to cannibalize the best of open source to create private differentiators raises the barrier of entry for competition. This market would naturally drift towards an oligopoly-like market equilibrium.
Like I said, I agree with your perspective on licenses. I would just also like OSS to be the great equalizer that instills innovation and disruption in the greater tech market place. But so long as tech giants can take any good new OSS, pay top dollar to recruit great engineers, and then throw them at OSS then I don't think this ideal vision will come to fruition.
I might say instead that the norms of open source software development -- attribution, collaboration, good faith -- are so baked in to small, high-trust communities that they might seem as though they'll be obvious to everyone. And then your software makes it way to the public and you realize that those were just assumptions and not written into the letter of agreement at any point.
I'm speaking as an outside observer on this.
And I say this as someone who has released all of his software within the past decade using either GPLv3 or APGL, for exactly this reason.
When they fail to give back by dodging taxes, paying minimum wages, spying on people, cornering markets, competing against FLOSS project/orgs they are breaking good faith relations (and the spirit of law)
Open source db software is suitable for these dual licenses - using it is free, but if you are going to sell products and services that are repackaged versions of the tool, you should pay the creator (like mysql).
This is simply not true in any meaningful way. Please cite real data. It's very hard to disagree with handwaving like this.
Both Google's official policy (which is super clear about this: https://opensource.google.com/docs/), and practice (releasing and working on tens of thousands of open source projects) say otherwise.
I would love to see the data that goes with this claim.
AGPL was a roundabout way of hinting that cloud providers should kick back some revenue and now that it didn't work the truth can come out.
How does AGPL force kicking back of revenue? The only way I can think of is if the cloud-provider choose to relicense the software (for a fee), because they can always fulfill the terms of the AGPL by publishing all their changes without paying a dime.
This is false. Seriously - i'm not sure why people on HN like to offer things as facts that they simply aren't ever going to know about.
Google in fact does pay companies that developed open source software that Google relies upon.
What you're saying is (I think): Google contributes code + projects back to the OSS community and sponsors OSS organizations.
I think if we could see the actual numbers — if it were possible to see Google's cloud revenue with associated OSS contributions — we'd see that what they're actually giving "back" is tiny, and it's the equivalent of donating to charities.
Since we don't know how many people actually work on OSS at Google, we can maybe use this estimate: https://twitter.com/mjasay/status/960563592683667456
Assuming Google pays ~$250k salaries to all of those folks to work full time on other peoples' projects, they're spending about $500mm/year on OSS while making ~$2bn/yr on just Google cloud. And that's horribly optimistic, I doubt much of that money is going to projects Google doesn't control.
Google's original OSS projects are different, I tend to like them. But given Google's market power the actual effect is to commoditize all the things Google doesn't expect to make money on. Kubernetes is great. Mesosphere is increasingly irrelevant because of it. OSS projects from megacorps tend to have the same effect as price dumping. They can afford to spend more money making something an non-viable business than most companies can spend at all.
Well, that's one way to put it I guess. I personally am OK with anyone taking my work and doing a ton of proprietary development on it. I wouldn't put it out there that way if I wasn't (and don't w/ my proprietary stuff).
We need to stop demonizing restrictionless development. Same with commercial/copy-left development of course, but I'm seeing too much copy-left righteousness these days. To each their own. Also, we need to stop being so prideful in our work that we consider some uses of it an affront. Sometimes when you make things available to the world at large sans restrictions you have misusers. That's ok. But hating the proverbial man tends to only negatively affect downstream users at large. MongoDB can do what it wants, and should commercialize where it wants, but all this corporate hatred coupled with openness righteousness should stop being used as justification.
> _Also_ I bet some random licensing folks are crapping their pants at IBM right now. I'm ashamed at how funny that is.
So are their customers and all users who lost some freedoms today because of perceived self-righteousness. Ashamed is a fair word for grinning after pivots like these, but I definitely don't see a problem with the pivot itself. Again, to each their own.
I'm not sure what planet you live on, but the GPL and other various copy-left licenses have been on the slow decline for years in part due to things like SaaS negating the use of everything but the Affero GPL and the social 'implications' of using the GPL ("poisonous", "viral"), while the use of extremely liberally-licensed, "corporate-friendly" permissive licenses has skyrocketed.
You don't have to look far (I've seen it more than once) to find people submitting issues on places like GitHub to completely relicense a project, just because it was GPL. Even here, every time a piece of code with a GPL license is attached and posted, you can be certain of someone pointing this out.
There are technical factors involved (like what's the deal with JavaScript licensing), but ultimately less projects choose the GPL -- or any other "demanding" copy-left license -- than ever before, so I have no idea what you're talking about, other than a perceived persecution complex where you think people are trying to "stop you" from using their code?
Of course, the funny thing is you say we need to stop "demonizing" restrictionless development, and of all copyleft licenses, the Affero GPL actually has risen in usage. But that's not because there's a big mean group of copy-leftists making people do it through blackmail. It's because it's risen in usage in corporate-sponsored, open-core projects, precisely to disincentivize systems like large, already-rich SaaS companies sucking the money out of their core customers by requiring them to share the source code for their changes (which they are often unable to do, making it effective). Corporations that sell open source software exactly understand how this game works -- they don't want other companies directly eating away the bulk of their revenue streams by just slapping a stupid UX and some user management patches on top, and so they license their software in an appropriate manner to try to cover all bases (source available, but without already-geared-up companies eating away their direct lifelines).
You'll also notice most of the companies doing this strategy aren't already highly-powerful, highly-monied SaaS companies. They're often much smaller and starting off, trying to get their software in the hands of users, while retaining revenue leads. Highly powerful companies like Google can afford to just release everything under non-copyleft licenses like Apache or MIT. They can subsidize the development of the software through established business.
But I imagine most people on this website wouldn't see these companies as being "copy-left righteous", only "protecting their investment". Unsurprisingly, this kind of understanding doesn't seem to extend to individual developers who license their code under a copyleft licenses (who are "righteous", and have no reason to care about anything other than the most people possible using their software).
Maybe the "copy-left" righteousness you're seeing isn't a massive proliferation of copy-left licensing, but actually a result of people getting wise to the way this conversation plays out. After all, if I'm going to be accused of being righteous, I might as well use the GPL, since apparently anything less than a free-for-all isn't acceptable to a lot of people.
The planet that recognizes that proclaimed righteousness (what I wrote about) has nothing to do with adoption (what you wrote about). If anything it makes the righteousness stick out because it goes against what people are choosing. I rarely see GPL devs demonized for how they choose to give their code away, or blog posts and evangelists espousing anti-GPL, or the straggling person "eventually coming out and calling it poisonous", or justifications on non-GPL changes as claiming corporate harm.
I have no statement on license prevalence and it is unrelated to my comment. My statement is about justification used and being overly prideful of their work. Change and be done. One way is not necessarily better than another, and companies are not all bad, and that's not only who you are hurting with these changes, etc. But when I hear complaints about the company using up all their hard work like it's some zero-sum coffer being depleted, I don't pity them. I know the intent is guilt and I don't think it's a good look.
I'm not! I love permissive OSS licenses, I think they're great until they get abused.
What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
This license from MongoDB is an unfortunate side effect of that. I don't think anyone there wanted a weirdly restrictive license, but I do think they want to build a healthy business on top of their work. And that's something I want them to be able to do as well.
There's a big, big difference between companies in an oligopoly position and normal companies. Permissive OSS grew up in a world that wasn't a weird oligopoly for good reasons, but a lot has changed in the last 10 years and it's downright dangerous to license things permissively and try to build a business at the same time.
Example: we built an Edge Runtime, it's under a permissive license, if we're successful I expect we'll run into the same problem DB companies have and then have to navigate around that: https://github.com/superfly/fly
I think they're great even when they get "abused" (for that definition of "abuse" which I don't agree with).
> What I'm demonizing is overly powerful megacorps owning an unreasonable amount of the available "tech" revenue.
Whether or not that is a problem is a different discussion, but suffice to say the license change will not solve or change that. It is naive to think so.
> it's downright dangerous to license things permissively and try to build a business at the same time
Well, if you attempt to build a business on the permissively licensed thing, of course. I'm not sure I concede that building a business on permissively licensed thing, thereby changing its license, is required. Building a business around it? Developing it with funds acquired on other business? Remaining small and not growing it beyond its original development? All of these are sustainable development models too. Before being so quick to blame these "megacorps" like they did something wrong, consider whether the changes to correct this "wrong" even accomplish the goal and whether that goal has any value of being accomplished. The intent of the license change has less value than its practical effect, and the idealistic way we'd like open source to sustain itself and be profitable is not always the pragmatic one. Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
> Calling them "megacorps", saying they are the problem, saying you have no choice but to change your license, etc all of this is what I mean about the ill-perceived righteousness of license restrictions.
They _are_ megacorps. It's ok to be fine with megacorps, but it's a little silly to pretend they're not.
They are a problem (you can disagree with this). We'd be better off with 20 smaller companies than one large Google. More innovation, less barriers to competing, etc, etc. It's not really righteousness, righteousness is more a moral stance than an "oh shit this is a bad state we're in".
Until communities refuse to sign CLA that let projects bait-and-switch to another license once they have a large community and want to now take buckets of VC money.
It's totally rational to create a license model that prevents hosting to third parties, but still allows end users to adopt the technology without paying. As has been pointed out elsewhere, that may not be right for all OS projects, but it should be an option.
Aren't you glad it isn't you! ;-)
Any other company (like Compose) can do the same thing and there are several hundred vendors offering various options. MongoDB Atlas is entirely this, and seems to be doing well by leveraging their own expertise and moving faster than the others.
If MongoDB now wants to change the license then they're free to do so, but they'll face the consequences of becoming more proprietary with their offering. It may help or it may hurt, but there's not some big universal argument to be made. If you don't want to make and give away free stuff, then don't. The rest of the world will still manage just fine.
Obviously the service is managed and that has value, regardless of the backend and your opinions on how they run it. Perhaps your issue is with all the customers who want and pay for this rather than providers meeting a need.
Why does this debate consyantly flare up again and again? No one is exploiting licenses, if you release something as open source then it’s open source, amongst other things you give up any claim to the money others might make using your software. That is your choice, any no one is exploiting you or your work by using the software within the license you granted them.
People need to stop this attempt at having “financially closed” open source. If you want you software to be propriataty and have limitations on usage just do that. Don’t release it as open source and cry fowl when other treat it like that instead of treating it like you had a proprietary license on it.
AGPL style licenses impose restrictions on usage, thus violating freedom 0 in the Free Software’s definition or Open Source’s rule 6.
AGPL should have never been allowed, precisely because it opens the door for commercial entities to eat their cake and have it too, being the kind of license that can be effectively used to disallow commercial products built on top.
In my opinion your own modifications that are never distributed (by the copyright definition) represents mere usage. And we’re software developers after all, personally I patch most of the libraries I end up using and some patches I may contribute back, but I’m definitely not required by any license.
“Open Source” and “Free Software” have great sex appeal, I get it, but if you can’t deal with competitors benefiting from your work, which is the whole point of such an endeavor, then don’t do FOSS.
Go proprietary and be honest about it.
No, not in the commonly understood sense of "usage" as "field of endeavor". I understand what you're getting at but anybody can use AGPL'd software for anything. They just need to publish any modifications they make to said AGPL'd software. It's a restriction, but not on "usage". Such a restriction would be something like "you can't use this in the nuclear industry" or "you can't sell this".
Writing a script that interacts with said software to enhance or modify its behavior is as easy as clicking an UI button and I don't see a difference.
Also the "understood sense" is irrelevant. Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
The genius of the GPL licenses has been that they are just copyright licenses handling distribution, but that don't impose any restriction on usage. This was by design. Here's Richard Stallman's own take on "freedom 0": https://www.gnu.org/philosophy/programs-must-not-limit-freed...
> "They just need to publish any modifications they make to said AGPL'd software"
N.B. that's in fact a huge restriction, being a matter of costs too, because "publishing any modifications" costs both time and money.
> Usage is whatever you do with it that's not distribution in the sense defined by the copyright law.
That is the tricky part. A video streaming site is considered distribution by many copyright laws. There was a time where simply using a website was not considered distribution, but then scope of copyright was extended and concepts like "public performance" and "making available to the public" was applied to works provided through web services.
GPLv3 however gives an additional permission that allow "interaction with a user through a computer network", even if copyright law would forbid it.
Personally I agree with copyleft licenses for as long as they are just restricting distribution as defined by copyright law. This because IMO there needs to be a clear, lawful boundary for what FOSS licenses can and cannot restrict.
Will look more into it.
I even didn't know it was AGPL until now (I'm not MongoDB user). Because so many people seem to use it as if it is Apache License or something free of charge. I haven't see any warnings on AGPL and its implications in MongoDB tutorials on the internet.
Well, that isn't true any more. If you start selling MongoDB functionality as a service, you now have obligations, even if you didn't modify it.
As for what they're trying to accomplish... it sounds like a slightly different version of the AGPL (in spirit), and while I'm not the biggest fan of the AGPL and similar licenses, it's not the abomination that the Common Clause stuff was. This seems to just be saying "if you want to offer a MDaaS (MongoDb as a Service), you have to release the source code to the entire service". It's probably not a license I'd choose, but it's not exactly unreasonable.
Disclaimer: I haven't read the entire license yet, so my comments above are based on other people's summaries / the text of the article linked above. My opinion is subject to change once I've had time to digest this fully.
Disclaimer: My company Storj is building a distributed Amazon S3 competitor and we are actually partnered with MongoDB. We share revenue with MongoDB for any customers they bring us.
The author or company building the software requires money in exchange for using their software. The revenue acquired through the license is then use to pay for additional development.
Revenue sharing seems to imply some kindness / goodwill agreement.
Paying for a license won’t get you customers but paying for referrals will
Kubernetes was donated to CNCF and there are a lot of Google SWEs working on "removing Google" from the actual project to make it more cloud native.
I really have a hard time picturing the success of CNCF/etc without the big names.
so google should give everything away AND also need to pay to every open source project, besides that smaller player don't?
sorry the world does not work like that. open source means giving and taking, not only taking. google might not be an angel, however restricting them to pay - OPEN SOURCE, non restrictive work - is just silly.
I’d hazard a guess that even the most prolific open source individual contributors use more open source software written by others than they contribute to.
Nobody individually, could really ‘pull their weight’ with respect to contributing back to the community. I doubt most corporations could feasibly contribute back more software than they use, even if they tried.
They do help in some respects: I don't think Kubernetes would be as successful were it not for the big conferences put on by the CNCF. And, of course, lots of companies actually are contributing code back to Kubernetes particularly (and Linux, and some other projects). But there are also a lot of popular open source projects which are used by lots of big companies but don't get either code or money from them.
Still, I wonder where MongoDB actually wants the boundary drawn. Anyone that tries to offer the MongoDB protocol as a service using the official code? Or is it if I provide a database interface to a MongoDB instance? Or is it only if the actual MongoDB interface from the MongoDB server is provided? I haven't read their new license but I have a strong feeling that it won't be 100% clear yet.
I believe there is also case law that supports the legality of reverse engineering for interoperabilility as well. I wonder if that has implications on this.
This is just another highlight of the cloud vendors making it very difficult to build a business based on open source infrastructure software. Either you pick an infectious license (like AGPL) or you go open core. Otherwise, if your project gets popular, the cloud providers will offer it as a service, which will eat into your revenue.
Alibaba & Tencent have been offering managed MongoDB offerings for a while but MongoDB, Inc. has historically not made any major investment in its own managed offering (Atlas) for that market.
This license shift is aimed squarely at AWS, who is rumored to be ready to announce/release their own MongoDB-compatible service at AWS re:Invent next month.
If I want to use MongoDB in my ecommerce app no worries. If I want to simply use MongoDB offer some minimal improvement or added functionality, call it ZongoDB and sell subscriptions... not so fine?
No, because such a license would - by definition - not be an Open Source license. That's basically what the Common Clause says, but a license with that clause attached isn't OSS.
If your web app uses MongoDB (or any SSPL licensed software) to provide a value that is not substantially MongoDB itself, you are not making the software available as a service. If your code facilitates making MongoDB's features available to other users, you are providing MongoDB as a service and are obligated to make all that code available under the SSPL.
No. Open Source always implies freedom to use for any purpose. There might strings attached such as the need to open-source modifications as well, but if usage itself isn't free, it's not Open Source.
They struck the portion of section 13 that allowed for such combinations.
(You can see it in the redline they published here:https://webassets.mongodb.com/_com_assets/legal/SSPL-compare...)
Can someone enlighten me on the significance of this piece of text? Does it mean you're not allowed to edit the license and publish it under the same name, or does it effectively copyright the entire license text? I'm gravitating towards the former since this is a case where the text was edited but renamed, but I'd still like some clarity.
As an aside, is it even possible to copyright a license? There's a copyright notice so isn't this technically plagiarism?