(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.
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).
> 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.
> 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".
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.
> 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'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.
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.
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.
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.
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.
> 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.
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:
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.
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.
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?
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.
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.
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.
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.
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.)
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.
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 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.
> 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.
> 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.
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.
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.
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?
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.
> 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.
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.
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.
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.
> 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.
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.”
That... is 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.
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++.
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...
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.
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?
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).
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.
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.
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?).
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.
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.
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.
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.
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?
In my opinion whenever SSPL is classified as Open Source license or not they could have done better job rolling it out.
Making announcement and having all MongoDB Community Software change license the same day for all current major versions (not just new major releases) is not very friendly to users of such software
Many companies which are serious about their software licenses will need to evaluate whenever they can use SSPL, in the meanwhile being left without access to security updates... not a good place to be.
Though I suspect MongoDB would just like such companies to use Commercially Licensed Enterprise Version and not deal with all these Open Source (or not) license change
Advance Submission to OSI and validating it as Open Source License would reduce the concerns of companies looking to use MongoDB Community as they could rely on OSI's legal analyses rather than perform their own
SSPL explicitly states that anybody who wants to offer MongoDB as a service — or really any other software that uses this license — needs to either get a commercial license or open source the service to give back the community.
Looks like a pretty straightforward extension of GPL principles, by replacing the linking of licensed code to remotely calling the licensed code.
It can have a lot of implications for service providers and commercial developers alike, depending on the way commercial licenses will work. (Some DB licenses have pretty stifling clauses, like Oracle's or MS SQL's.)
AGPL requires you to share the changes to the licensed software you make available, that is, changes to the MongoDB itself.
It was like LGPL in the local case: you alter the library and make it available through the software you link with it, so you have to share the changes you've made to the library, but not the rest of the linked code.
With SSPL, it's like the full GPL in the local case: if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.
Another tricky question is where the border line is. If I write a wrapper that interfaces with MongoDB and repackages its data, then makes them remotely available to the rest of my service, do I only need to share the wrapper? If not, and any network connection that substantially uses an SSPL piece counts, then do I have to share my internal monitoring system? Am I even allowed to connect closed-source data analysis tools to an SSPL database? Etc.
> if you take the licensed software, and link it (via rpc / network) to your other software, you must share not only any changes you've made to the licensed part, but the whole thing that uses it.
Slight modification makes this accurate to the SSPL: if you take the licensed software, and link it (via rpc / network) to your other software which you use to offer the SSPL licensed software as a service, you must share...
> Another tricky question is where the border line is.
Ultimately the trigger of the SSPL is whether what you offer publicly is the SSPL-licensed software as a service. It doesn't trigger the SSPL if you make MongoDB available as a service to your application internals as long as what you're making available publicly is not "a service the value of which entirely or primarily derives from the value of the Program or modified version..."
Playing a devil's advocate. Suppose somebody made a clean-room implementation of a MongoDB driver that contacts MongoDB, then passes the data to a MongoDB-compatible interface that shares no code with MongoDB. This wrapper is duly shared. Can that guy then offer a SaaS MongoDB-compatible DB by exposing this driver, connected to a real MongoDB, without a commercial license?
As we notice, all that SSPL would require to share is shared in this case.
Then a wholly-owned subsidiary could build various value-added services on top of that MongoDB-compatible thing without a commercial license. This of course would fail if the wrapper would need to be licensed under SSPL, too.
The SSPL neatly sidesteps that workaround. It does not specify anything about the provenance of code, or the extent to which code is shared with the licensed software's code.
If you offer a service based on the licensed software, and the value of the service being publicly provided entirely or primarily derives from the licensed software, every bit of code -- the clean-room driver, the compatible interface, the admin scripts, UI for management, etc. -- used to offer that service must be made available under the SSPL.
Vice President of the Open Source Initiative here.
MongoDB submitted this new license for approval by OSI at the same time that they announced that they'd relicensed all of their code. We wish they'd started the process prior to the announcement, but what's done is done. The result, however, is that at this moment, MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE.
As the license review process only started this morning, there's no way to estimate how long the process will take. There also is no guarantee that the license will be found to obey the Open Source Definition, and therefore no guarantee that it will be approved.
Hopefully this will all be resolved soon, but there are far too many question marks around this license (and therefore also around any software using it) right now. It's probably best to limit your legal risk by not upgrading to an SSPL-licensed MongoDB at this point. The previous AGPL-licensed version should always be available.
On the other comments in this thread, even though MongoDB have "submitted" to having the OSI review their license, OSI still aren't capable of restricting anyone's rights on the use of the phrase "open source" including MongoDB's.
I can see your organization tries to make sure that there is an approved set of principles that identify libre/free software which is good. The phrase "open source" has been used in myriad ways since its early days, and not just for software.
I'm a programmer who has written open source since 2000. I would defend you when it comes to the benefits of libre software, but you can't restrict others over using something that you don't legally own.
So, yes, technically, OSI does not own the term open source, and it could be that this license does comply with everything set out in the Open Source Definition (https://opensource.org/osd), and that means that, technically, "(the latest version of) MongoDB is not open source" is overstating the case.
Except that, as a non-lawyer developer who generally agrees with the Open Source Definition, "under an OSI-approved license" is my working definition of "open source". I believe the same is true for many others. And, under that definition, if Ms. Brasseur doesn't consider it to be open source (yet), I'm happy to fall in line with that.
She went on to say the magic words that mean so much more to me on this front than any debate about who gets to own the term: "It's probably best to limit your legal risk," and, "at this point." OSI's recommendations are a key part of how I limit my legal risk, and they're working on vetting it as we speak. My best course of action is to sit on my hands and wait for their advice.
Between Cygnus/Red Hat and Mozilla, I've worked for open-source-based companies for 7 years of my career, and never once heard or believed "open source" in lowercase to mean "OSI-approved."
I appreciate what OSI does, and do value an OSI review and endorsement, but you're seriously reaching here and trying to double-down on it.
Edit:
To be clear, I think the OSD captures what open source is, but OP tried to say "We haven't reviewed it, so it's not open source," not "We haven't reviewed it, so WE don't know it's still open source." Whether or not and when OSI gets around to reviewing something has zero bearing on whether something meets the OSD, even if we are going to assume that's the de facto definition.
I find the idea the VP thinks we need to wait on them to deliver their judgment from on high to be, frankly, offensive. OSI didn't successfully get the trademark on "open source" for a reason, and I can read a license myself.
> Between Cygnus/Red Hat and Mozilla, I've worked for open-source-based companies for 7 years of my career, and never once heard or believed "open source" in lowercase to mean "OSI-approved."
That bullshit.
If that wasn't the case then Microsoft's Shared Source licenses could also be considered "open source", licenses which completely restricted commercial usage. Thankfully the world did not fall in that trap.
Without a working legal definition, the term "open source" becomes (1) meaningless and (2) a legal minefield.
Basically you've been spoiled by OSI approved licensing because our industry rejected anything else. We could've had a different industry and yes, all those bullshit projects on GitHub without a license are a legal minefield.
Yeah, but that's a really dangerous position to take and if they'd work with me I'd be quick to set them straight. Because that path leads to legal adventure.
I'd add "redistribute" to the GP's definition, but the point stands that the definition of "open source" is not "licensed using an OSI approved license"
Whether or not it's OSI approved or not isn't relevant, but if it doesn't meet their definition or something similar (https://opensource.org/osd) then it probably isn't what most of us would call open source.
How about I create a license called the ABA (anyone but amazon) license. If you're not Amazon/AWS/a subsidiary, it's just the MIT license. If you are, then you have no rights to use the software. Would you call that an open source license? I wouldn't. An important point (I thought) of open source was that the rules are the same for all, whether you're using it for personal projects or the biggest business on earth, whether you charge money for it or do it for free.
That's a fine interpretation of the term for amateurs.
By which I mean, it's probably fine to think of things that way when you're working in an amateur capacity. If you're working in a non-amateur capacity, thinking about things that way could result in unwittingly exposing yourself to more legal risk than you want.
I don't think simply checking that the license is "OSI approved" gives you many legal guarantees. There are currently 83 "OSI approved" licenses containing a variety of terms, from aggressively copyleft to extremely permissive: https://opensource.org/licenses/alphabetical
I don't either. . . we might be playing a game of moving goalposts here. I was specifically responding to the observation that, "Open source for most people means whether you can see and modify the source code.", and saying that that, while that is a workable definition, it's probably not one that most people want to use.
You might want to be a little tighter with that definition. You can find the source for all sorts of crazy stuff. And with that, you can modify it.
Oracle or Microsoft or any other copyright holder that didn’t release that is going to be ticked off at you.
There has to be some element of the author wants you to have it.
I know this sounds silly and pedantic. I think there have been organizations that ignored copyright and released stuff they didn’t control the rights to.
You might want to tack on something about the authors want me to have access to this.
… And I think this has exactly been @bunderbunder's argument from the start? That the "definition" put forth by threeseed is naïve and could at best be usable on an amateur level, but as soon as you start having money involved, you really want a more in-depth/verbose/specific definition (like the one the OSI provides), rather than simply being "I can read (and thus modify) the source."
Part of why I originally used the term "non-amateur" instead of "professional" when I described people who shouldn't work under that definition is that, while students and maintainers of open source projects might not be getting paid for what they're doing, they still have compelling reasons to be more careful about licensing.
One worst-case scenario for a student might be that some software licensing snafu threatens their academic work, and, by extension, their whole career. And open source project maintainers have an ethical responsibility not to get users of their work into legal hot water.
For those people, falling in line with OSI offers a huge advantage: You can't avoid crossing the software licensing legal tightrope. But, by sticking to working with OSI-approved licenses, you can at least ensure that you're working with a net.
> That's a fine interpretation of the term for amateurs.
That's a seriously polarizing statement that you've made.
While I understand that your argumentation is from points of law, I think you need to realize that the term open source, was pushed by us, the developer community and so I feel that it is us amateurs that have the right to maintain the heart of the law. So, revisiting the heart of the matter:
"We had identified free software as a promising approach to improving software security and reliability and were looking for ways to promote it. Interest in free software was starting to grow outside the programming community, and it was increasingly clear that an opportunity was coming to change the world. However, just how to do this was unclear, and we were groping for strategies." [0]
So, what MongoDB has done is in fact increased (imho) the open source aspect of their offering by attempting to curtail corporate abuse. You should be thanking them.
No, it has nothing to do with "amateurs". Whether the source is open and what the license dictates are two wholly different things. The danger is exactly in conflating the two.
Take for example the NPOSL-3.0:
A variant of the Open Software License 3.0, this license requires that the organization using it is a non-profit and that no revenue is generated from sale of the software, support or services.
The source is open, but you can't use it outside of non-profit orgs. It's "Open Source™", it's approved by OSI, and it can still get you in legal trouble.
Huh, how on earth did that get approved. It violates Section 6 of the definition: "No Discrimination Against Fields of Endeavor" (which specifically has the example of discrimination by disallowing software use within a business).
Personally I never liked the OSI's definition of "open source", and the FSF definition of free software has always felt (for me) to be far more fundamental.
If you never liked the OSI's definition of "open source", what do you think about the Debian Free Software Guidelines?
About the discrimination of fields of endeavour, please read the sibling comment to yours. I think you and the grandparent have both misunderstood the license.
I went and re-read Section 17 (the only section that is different from the OSLv3) and yeah it looks like tl;dr legal misrepresents what the license requires. Effectively, it requires that if you redistribute it and want to do so under the NP-OSLv3 you must make a declaration that you're a non-profit and so on -- otherwise you must distribute it under the OSLv3 and clearly state this is the case. (I don't really see the benefit of such a license, but each to their own.)
Looks like I was wrong. Regarding the DFSG, I think it was necessary (according to Bruce Parens it was the DFSG which convinced Stallman to distribute his four freedoms definition more widely). I think the DFSG is a decent set of guidelines that help avoid legal trouble for Debian by having clear requirements, but I don't think it's a good definition for a movement's primary purpose. In many ways the DFSG and OSD can be seen as re-statements of the four freedoms but without any strong justification for why these particular conditions are necessary for a license to be good -- the four freedoms can be explained by explaining how each freedom is necessary to ensure that users have control over their computers.
For an example of why having strong fundamentals is important, the OSD doesn't really have a stance on DRM -- while the free software definition clearly does (even though it predates any modern concepts of DRM).
Thanks for changing your mind on receiving new information.
DFSG and the OSD are essentially the same thing, having been written both of them by Bruce Perens. Main difference is that Debian doesn't certify licenses: they ship software, so they look at the whole packages, so to speak. OSI only certify licenses, they don't ship software.
As to what the DFSG and OSD do that the FSF four principles don't, I think they are more detailed set of rules one can apply when trying to figure out whether some software is free or not. IMHO, the FSF principles are less operationally useful, despite describing categorically the same set of software.
> DFSG and the OSD are essentially the same thing, having been written both of them by Bruce Perens.
Right, and I knew this is what you were getting at. I guess my main point is that having a working guideline for acceptable licenses for a distribution makes complete sense (after all of the moral viewpoints have been debated to death you have to ship some code eventually), but using those guidelines as the basis of a movement doesn't really (at least not as much as basing a movement on an a set of ethical axioms). So I would say I favour the DFSG over the OSD purely because of what it is used for and represents, rather than because of the (almost non-existent) differences between the two texts.
But of course, I'm biased since I'm far more in the "free software" camp than I am in the "open source" camp -- purely because I think bringing it back to discussions of ethics is quite important (perhaps more than ever).
You've misinterpreted the license. What it says is that the licensOR (not the licensEE) is a non-profit. That is, by publishing your original software under the NPOSL, you claim that you are a non-profit organisation. That's it.
Nowhere does the license say that you can't use the code outside non-profit orgs. In fact 17.d says very clearly that if you're not a non-profit, you are allowed to distribute your modified works, but under the original OSL license, not the NPOSL. So you can use, modify it and distribute it, only with a complication in the licensing.
The other amendment the NPOSL adds is where the original OSL gives a grant of patents and a warranty of provenance, and the NPOSL explicitly doesn't, because it's designed for non-profit companies, which have no money, so it's intended to reduce legal exposure.
It's a Free Software license in my opinion, and I bet you a drink that Stallman and the FSF would consider one too, even if they would not recommend using it.
Also note that the license's author is Laurence Rosen, who was General Counsel of the OSI, knows more about software licensing than most people, and who explains the details and rationale of the NPOSL in [1]
If you have any other license that's OSI-certified and you think is non-free according to the principles of the FSF, I'm interested in learning about it.
One thing to take into account, though, is that the OSI is a certification body, and the FSF isn't.
Thhis means that the list of Open Source (according to the OSI) licenses is closed and published on their site. The FSF gives a set of principles and also publishes a list of licenses with some analysis, but the FSF's list is non-exhaustive, nor does it pretend to be. There are infinite potential free licenses that the FSF will not list, because its doesn't count license certification as one of its goals.
Yes, the OSD tries to include legality in "seeing and modifying". If you regard Open Source as just "seeing and modifying" the source then anything that you can get the source code for is Open Source. This is most definitely not the case, as illustrated by my previous example of Windows 2000. Please see [0] and [1] for more info. Confusingly, there are still copies of the W2K source on github which have an MIT license in the root which is, I assume, false and unauthorized by MS [2].
On my side those cases are categorised as "Public source" and the respective license terms are then labelled as freeware for most cases, as a sub-variant of Proprietary license types. The other two variants would be Purchase or Subscription.
From a licensing compliance/verification perspective, being OSI approved is a good help to guide developers and reduce the effort of processing the applicable terms. For the auditor itself, the OSI stamp is OK but not something critical.
Looking better, we simply don't even use the terms Open Source nor FOSS on our procedures to be inclusive of the commercial/closed 3rd party products.
Not sure anyone actually thinks "open source" is a term owned by an organization and the gp didn't say they were restricting Mongo, so I'm not sure if your clarification is necessary.
It's like someone claiming certain software doesn't scale. There is no need to clarify that the author doesn't own the word "scalability".
Op is speaking for the OSI's opinion on whether it's open source or not.
The OSD may not be the de-jure definition of "open source", but it is the de-facto definition. The statement above is correct in all but a trivial, pedantic sense.
Not just trivial and pedantic, this has been a common avenue of attack over the years in an attempt to dilute the meaning of the term. Such as when Microsoft made a concerted effort to try to redefine open source as "non commercial" source available software.
> because the OSI don't appear to have a right to restrict use of the phrase
You are really hung up on this. Where did they say they were restricting the use of the phrase? If they said: "MongoDB is not good software" would you be saying they aren't allowed to restrict MongoDB from saying they are good software?
This VP specifically states MongoDB "IS NOT OPEN SOURCE" presumably referencing their own organization's definition of open source. What's worse is their current definition technically qualifies MongoDB as open source. She conflates a non-OSI-approved license with the definition of open source very blatantly.
As someone just above said open source for many simply means the source code is open (can be viewed).
Edit: Realizing now that "open source" may be a genericized trademark held by one of their board and we may need to ignore their assertions in this thread.
> What's worse is their current definition technically qualifies MongoDB as open source.
I don't agree, the modified section 13 appears (at least to me) to violate the spirit, if not the letter, of section 9 of the OSD:
> 9. License Must Not Restrict Other Software. [...] For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
The new SSPL requires that all of your server configuration and tools be distributed under the terms of the SSPL. This is so badly worded that it could include your operating system kernel (which, on Linux, would not be possible since GPLv2 is incompatible with this new license).
Also, the scope of "providing a service" isn't limited to network services (which is what you'd think). No, it applies to any service "includ[ing], without limitation [...] offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.".
I'm sure you can easily come up with some examples whether this concept of "providing a service" will run into strange consequences when your accountant is giving you a download link for MongoDB as well as all of Windows.
Open source is mostly objective, unlike 'good software'. The parent comment stated in caps that MongoDB is not open source, which is objectively untrue. It's a silly thing to bicker about, but the original should have probably said something along the lines of 'OSI approved open source license'.
The only objective definition of Open Source I know of is OSI's. Everything else is a hodge-podge of whatever the user of the word feels it's open. Is it reading the code? Modifying it? Redistributing it? There's no consensus besides OSI.
But their definition does not restrict it to OSI approved licenses, so their assertion its not open source because it hasn't been approved is not valid.
> I can see your organization tries to make sure that there is an approved set of principles that identify libre/free software which is good.
The OSI doesn't define what Free/Libre software is, the Free Software Foundation does. The OSI is in charge of the common definition of "Open Source" software, which is accepted outside of non-software or idiosyncratic usages (such as "open source is when I show my references" or "open source is when I derive my conclusion from publicly available information" which is becoming the common definition in the intelligence field.)
It's good when we have a common definition, and discuss that definition rather than the label; it's a waste of time to argue "of course it's organic; it's carbon based!"
One thing that we can both agree on is that more people are familiar with the OSI's definition of "open source" than are familiar with your personal definition, so it's probably more productive to talk about the one more people are familiar with.
While OSI may have coined the term "open source" as a reaction to the word "free software" in the past, it did not invent the idea of free software. Rather, the term open source was a reaction to the desire for commerical enterprises to avoid saying software was free.
Now it rejects the same argument from developers of software to make a profit, which I find ironic relative to the founding mission.
Previously, Commons Clause was called out in aggressive terms in twitter, rather than seeking to understand the underlying rationale.
I am left to believe OSI views this as a useful political time to self-market, or otherwise sees licenses like this - which intend to fairly compensate software developers - as something that does not promote the interests of those that primarily fund it.
I'm sorry, but we don't need a gatekeeper anymore.
But we do need a gatekeeper - that's where you're wrong. Without it, we don't get a fair review of licenses by people most adept at understanding what Open Source is. Without it, we will go back to the wild west of licensing where we have hundreds of OSS licenses that each have their own little clauses and are written by developers, not lawyers, so they don't really hold up in court.
Open Source is for corporations to benefit from FOSS without the need to spend exorbitant amounts to acquire such functionality. But corporations are bound by a set of rules to operate, and as such, so should OSS licenses.
If open source were to revert to the old-style, write your own license if you want to, corporations will have a much more difficult time accepting the new software. OSS will probably die a nasty death, and we will go back to tons of proprietary software running the biggest apps.
The OSI is non-political and for you to argue such is silly. The organization has one goal: to make open source easier for business. What political nature can you see in there? Do they ever restrict anyone from making money off their creations? (The answer has always been NO)
So some developers want to make money on the more advanced features of their open source project. Well, if it happens after software has been around a long time (ala Redis) then people are going to complain. It sucks to have to go from a free model to a for-pay model, but I understand the motivations. I don't think any developer should be kept from making money for their work, but if they want to make money off of something AND control the source, DON'T call it open source, call it proprietary because that's what it is. The source is provided, yes, but that doesn't make it open source. To truly be open source it has to abide by the OSD and Commons Clause definitely does not.
So, is it time for new open source licenses? Maybe, but they should be governed by some committee and the OSI exists so why not them? You're arguing that we should move into an anarchist style of releasing open source... The time has come to make money!! Well, again, that's basically what proprietary software is all about.
There is absolutely zero reason why the concept empowering open source software, the free and open exchange of code and software, can't apply to the licenses themselves.
The reason I believe in open source software is that it empowers the communities and users behind the software, despite (and sometimes, in spite of) the leadership, nobody controls open source software. If the linux kernel went in a direction I didn't like, either with how they approve code change requests, or by adding in code that I don't like, I can subvert their control over the codebase with my own fork, with blackjack and hookers, and compete, because they ultimentally have no control over their codebase, it belongs to the community.
This should apply to licenses as well, there should be no authority, no gatekeeper, just the community.
You're right. There's no reason at all why the concept empowering open source and the free exchange of code can't apply to licenses. After all, software is shared freely by people with the skills to handle it, why can't we do the same with licenses?
Of course, this does kind of require that the people working with license experimentation know enough about law to provably know what they're doing. So perhaps the community might not be as large as might be hoped, as there are limits to what a self-taught not-lawyer can do when it comes to having legal standing.
Having observed this area for 18 years now, I'll say that gatekeeper (a party which has unwaveringly observed and stuck to delivering the principles of software freedom) is the Free Software Foundation. This is the only reason why users gravitate to "open source" - not its sexy name, but the freedoms such software provides when a user wants to use/apply it.
Back in the day, the founding president of OSI justified VA Linux making the "alexandria" project closed source (the software that ran Sourceforge.net back in the day - back when sourceforge.net was a good citizen). The remains of "alexandria" was forked to form other projects such as GNU savannah, and there was a later fork named GForge IIRC.
There is only one organization that has unwaveringly sought freedoms for users of software. I've firsthand heard it being accused of promoting communism, and sometimes have wondered if it went too far. At least, they haven't wandered in their principles.
For all his craziness, you've got to admire Stallman for his unwavering conviction of his version of what free software should be and allow. I don't know whether he'd be frothing at the mouth, or quietly thinking "I told you so..." about the current antics at Redis and Mongo...
The code for windows has been leaked and people could get the source. Sometimes companies have agreements for viewing the source of software they produce. These are two examples where the source code is visible, but this alone does not make them open source. There must be other attributes beyond just being able to see the source code.
If I give you some source code, with the license that you cannot run the software, modify the code or copy or use the code in any way, it follows your definition and is still useless.
Well, besides OSI's definition -- which I understand is being questioned in this comments section, so I suppose mentioning it is begging the question -- most of the bibliography and articles out there use "open source" in the sense I mentioned.
Microsoft was also aware of the accepted meaning, which is why they introduced their "Shared Source Initiative" back in the old days (note how deviously careful they were about the naming).
Honestly, this comment section is the first time I've heard about the OSI, I guess whenever I read articles that use "open source" I've assumed a definition that may not be technically correct. I would hazard a guess that my definition is probably more widely held but that could just be my personal bias.
The OSI is a respected organization that defends basic and non-controversial rights in open source. The underlying reasons behind the Anti-Commons Clause are unimportant if the execution leads to such an egregious violation of these principles. I support the OSI and their mission is important. Getting angry with them for protecting open source from bad actors who try to subvert its freedoms while reaping its benefits is ridiculous.
I'm not saying that MongoDB is in the wrong here. The new license is perhaps misguided in that it seems functionally equivalent to the AGPL, but after I read it I think it meets the OSD. However, MongoDB should have spoken to the OSI before switching their license to be sure.
> OSI was specifically created to subvert freedoms that the Free Software Foundation protects
This is one of those spots where knowledgeable people can disagree, because they're working with a different set of values.
To someone who prefers the Free Software model, OSI was created to subvert freedoms that the FSF wants to preserve. To someone who prefers the Open Source model, OSI preserves freedoms that the FSF is trying to restrict.
To the other 99% of humanity, this particular debate probably sounds a whole lot like the Judean People's Front vs. the People's Front of Judea.
(Edit: s/intelligent/knowledgeable/ -- better choice of words.)
This isn't really true. The FSF and OSI have subtly different goals but the definition of open source and free software are nearly identical. The OSI exists to be a non-political entity so that people who want to work on open source have resources to do so without necessarily participating in the politics of the FSF.
> The OSI exists to be a non-political entity so that people who want to work on open source have resources to do so without necessarily participating in the politics of the FSF.
In what way is the FSF any more political than the OSI, beyond trying to protect the defined freedoms of free software?
By inserting itself as the only legitimate body to define what "open-source" is, it is by definition engaging in politics, no less than the FSF.
> The OSI is a respected organization that defends basic and non-controversial rights in open source
It is rather assuming that the OSI is "respected" or that it defends "non-controversial rights in open source".
The right to take my code, profit from it and not share back is essentially what the OSI stands for and is thus not respected by me.
>In what way is the FSF any more political than the OSI, beyond trying to protect the defined freedoms of free software?
The OSI only concerns itself with defining open source and publishing a list of open source licenses. The FSF unquestionably concerns itself with much more.
>The right to take my code, profit from it and not share back is essentially what the OSI stands for and is thus not respected by me.
No, this is what open source stands for. If you don't want to write open source software, then don't. That's your choice. But the right to do exactly this is protected by both the OSI and the FSF, and I doubt you can find another authority which disagrees.
> The OSI only concerns itself with defining open source and publishing a list of open source licenses. The FSF unquestionably concerns itself with much more.
The FSF concerns itself with defining/defending free software, same as OSI does for open-source.
If FSF "concerns itself with much more", I assume you would not have a problem listing some of these things.
> No, this is what open source stands for. If you don't want to write open source software, then don't. That's your choice. But the right to do exactly this is protected by both the OSI and the FSF, and I doubt you can find another authority which disagrees.
The difference here is that the OSI was historically created as a response to FSF for this exact purpose, whereas the FSF was primarily created to defend copyleft, later adopting some non-copyleft licenses as well, so the exact reverse of what OSI did.
Ask the FSF yourself. Richard Stallman can be reached via rms@gnu.org and usually responds to emails within a day. The FSF defends the right for others to sell your software, and has wide-reaching political ambitions. Don't just take my word for it, ask them.
YOU have asserted that the FSF has "wide-reaching political ambitions", therefore it is upon you to provide evidence for this.
> has wide-reaching political ambitions
I am asking what "political" ambitions does it have, beyond protecting free software.
> Don't just take my word for it
The thing is, you didn't provide any evidence of the "political ambitions" you speak of and so you're quite right, I don't take you word for it, unless you list at least some of these ambitions.
Looking at both links it is completely obvious which is the political of the two. You are really stretching calling the Advocate Circle the same as the various FSF campaigns. Some of the FSF campaigns listed are "surveillance", "upgrade from Windows" and DRM.
> Some of the FSF campaigns listed are "surveillance", "upgrade from Windows" and DRM
All of these restrict your freedoms, so that someone else is in control of the program and not the user. This is very much what free software stands for. So in reality, you're disagreeing with the principles of free software themselves.
> surveillance
Directly interferes with you being in control of the program, if it spies on you, violating the principle of free software that the user should be in control of the program and not the other way around.
> upgrade from Windows
So the Free Software Foundation advocating for the adoption of Free Software. Isn't that what it should be doing?
> DRM
DRM, by its very definition, restricts the freedom of the user to run the software in any way they wish, thus violating the free software principles.
None of these imply a "wide-reaching" political agenda.
>> The right to take my code, profit from it and not share back is essentially what the OSI stands for and is thus not respected by me.
Nope. You are so very wrong here. The OSI defines open source so that licenses comply with the terms... that's all. They don't have any other agenda, period. Stating so shows a complete lack of understanding OSS and the OSI.
Stating so shows a complete lack of understanding of why and by whom OSS/the OSI was started and popularized.
It ignores by who the OSI was co-founded and promoted by, (ESR, O'Reilly etc.) and why, (as a response to FSF to make free software more appealing to corporations for the exact purpose I outlined in my original post).
You repeatedly became uncivil in your posts to this thread. We ban accounts that do that. Please review https://news.ycombinator.com/newsguidelines.html and follow the rules when posting here.
(That includes not using uppercase for emphasis. That's basically online yelling.)
> Open Source was a way to make free software acceptable to businesses, not subvert the FSF.
Read my comment again please.
I didn't say subvert the FSF, but some of the things the FSF stands for. This, as you correctly point out, in order to make it more appealing to businesses, which I didn't dispute.
The Open Source Definition provides a single point of reference for what it means for a project to be "open source."
Licenses are submitted for approval by those who wish to prove that the license provides the benefits and freedoms assured by the Open Source Definition and therefore by open source.
Licenses that do not provide each benefit and freedom in that definition are not not approved and are not—literally by definition—open source.
MongoDB recognises the value that a consistent worldwide definition of open source provides to the entire software development ecosystem and is seeking approval for their license to show their support and respect for the definition.
1. "Licences that conform to the OSD are open source". Agreed.
2. "Licences that do not conform to the OSD are not open source". Ok, let's run with that for now.
That is not what you said upthread. You said "MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE". Nope. Even for those who accept the OSD as the sole definition of open source, you haven't yet established whether MongoDB's new licence is 1 or 2. You cannot categorically (capitally!) say "IS NOT OPEN SOURCE" until you establish that.
Using basic context clues and inference, it's obvious she meant "IS NOT OPEN SOURCE [currently]". The license has not been approved as open source. It may be eventually, but it is not at present.
No. She's conflating "an OSI-approved licence" with "open source". The Open Source Definition does not contain a requirement that a licence must be OSI-approved.
And who is the trusted organization that makes the determination whether a license adheres to OSD? Unless you want to hire your own lawyer and make the determination yourself, the world must wait on OSI's review of the license. Until further proof is put forth, I also would not consider the new license to be open source. That is, it is not yet safe to say that this license is open source. This holds true for me, because OSI guidelines are organizationally justifiable and makes my life easier when dealing with auditors.
Rather than pontificating about terms and hilariously claiming unenforcable rights to commonly-used words, the OSI should look at the reason Redis, Mongo, and soon others seek to update their license terms. It's because development is simply not sustainable in times of cloud providers. Who does the OSI represent? Is their intent that nobody except cloud providers can earn a living, by commoditizing software?
1. The idea that OSI seriously thinks it gets to decide what counts as open source is laughable. This is akin to Linux being released for the first time, and Microsoft issuing a warning that they have not yet verified that Linux is a "real" operating system, and to stay tuned for their final judgement. The arrogance here is hilarious. I've been working in open source for years and I've never, ever heard of OSI.
2. All "open source" really means is that the source code is available in some way/shape/form, with no implication whatsoever made about the license of said code. "Free and open source" on the other hand implies a permissive license.
3. I don't know anything about the MongoDB license before or after these changes, I just despise the tone of this message.
So to recap. OSI is just some random organization with no bearing on what society decides open source is or isn't, and therefore what they say DOES NOT MATTER.
Open source is a term of art with an agreed upon definition, and it has been for 20 years which, not-so-coincidentally, is also when the Open Source Initiative was founded.
The fact that you've never heard of OSI means we've been doing our job well enough that you've never needed to know about it.
The fact that you've never heard of OSI does NOT mean that it's not legitimate, and frankly, that kind of rhetoric is just silly.
Something is "closed source" if you literally can't get a copy of the source code. What is the antonym of "closed source"? The opposite of "closed source" is "open source" and it means that the general public can get a copy of the source code. "A permissive open source license" on the other hand implies the things that OSI is trying to confer on the word "open source".
You are so off base. You may have been writing source-available software, but it's not open source unless you know the OSI's definition. THAT is what everybody abides by to make sure that the licenses are fair and in the spirit of open source software.
Open source is an agreed upon definition for software provided under an OSI or FSF approved license. To state anything else shows that you DON'T understand what open source is.
You see, for corporations to operate they follow a set of rules. Rules designed to keep them on the right side of the law. As such, without the OSD we wouldn't have any rules to understand what open source is. Do you understand that?
Open source isn't just for hobbyist programmers, it's used to run the worlds biggest software platforms.
I can't tell whether this is serious or sarcastic. It lacks the "/s" at the end, so I'll assume that you're serious.
> but it's not open source unless you know the OSI's definition.
> Open source is an agreed upon definition for software provided under an OSI or FSF approved license.
Open source software (by today's standards) existed before the OSI or even the term "Open Source" existed - the creators of BSD *nix, X11 and TeX all chose a liberal, open source license before a cabal around Eric S. Raymond would decide on a definition of Open Source and the term itself. The idea came after the actual thing existed, and the definition after the idea. So it would be weird to call something Open Source that doesn't fit the Open Source Definition (because the latter was conceived together with the term), but it would absolutely be possible for a software/license to be Open Source without knowing about the Open Source Definition, as is the case with BSD, X11, TeX and many Free Software programs.
Next, there is the idea of the Open Source Initiative approving Open Source licenses, which is a good thing because people can trust any OSI-approved license to be an Open Source license. However, not every Open Source license is OSI-approved, because OSI applies additional criteria (e.g. being reusable).
So, yes, it's possible for a license to be Open Source but not OSI approved, when it fits the Open Source Definition but hasn't been submitted, not reviewed, or doesn't meet the additional criteria set forth by the OSI.
The fact that your employer's legal department will mistrust your personal judgement of software fitting the Open Source Definition (for perfectly sensible reasons) doesn't make software not Open Source (any more than a US State can decide to make Pi a rational number or to make dolphins be fish).
I'm one of those guys running businesses with open source for 20 years - not once have I given a shit about OSI or FSF or their definition, and neither do the other folks I know that control very large budgets.
So no, it's not some universally-agreed on definition and trying to hawk it as such is dishonest.
Did the FSF & OSI help establish the framework that's allowing us to have this conversation? Yes. Do they get to dictate that conversation in 2018? Nope.
Regarding number 2: by that definition of yours, Microsoft Shared Source Initiative in the early 2000s was also "open source". See the problem with not having a precise and standardized definition?
People wouldn't say "free and open source" or "a permissive open source license" if "open source" was already sufficiently descriptive, so I think in the back of their minds people already believe what I put forward here, at least a little bit. If the source code is available to the general public, it is open source. The source code is in the open. If a company decides to release source code with no license at all to redistribute or modify, solely so people can verify that their software does what they say it does, they still should be applauded for at least sharing their code rather than keeping it closed source, and what they would be doing would in my book still be "open source". Once again, if the source code is open, it is open source. If this wasn't the common definition, then people would never say "permissive open source license" because it would be implied.
Instead we have created this environment where if you aren't willing to "go all the way" and give people the right to modify/redistribute your code in some permissive way, you are basically pressured to not release your code at all. As a community we would have access to more code bases if this wasn't true. I totally agree that companies should embrace permissive open source licenses, but when that doesn't make sense, I totally think they should embrace non-permissive open source licenses. This is a minority opinion, however.
> All "open source" really means is that the source code is available in some way/shape/form
I think that, in practice, there are very few people who have been around the block a few times, and still see things that way.
As a concrete example, consider the Microsoft Shared Source Initiative. That particular (arguable) boodoggle is the closest I can think of to a real test of whether there's a broad consensus on what "open source" really means. My impression is that most everyone who's looked into it agrees that a couple of the SSI family of licenses are "open source", and the rest are not, and that they generally agree on exactly which ones are and are not.
I would say that if "some way/shape/form" means I have to be a licensed user of the executable code who signs an NDA in blood to get the source code, and may not even share modifications with others who have similarly obtained the code, then it's probably not "open source". It's just "source".
Code that is available because someone leaked it is also available in some way/shape/form, yet probably doesn't count as "open source".
Not every situation in which second or third party outsiders have access to source code is "open".
We don't have to accept OSI's exact definition with all its quirks (WTF is "technology-neutral"), but the salient features of OSI's definition jive with the widespread understanding that open source allows basically allows free redistribution and use of a program in source code form, with or without modifications.
MongDB submitted their license for approval, so obviously it matters to them. Whether you think it matters or not is irrelevant, you're just some random HN user with no bearing on what society decides open source is or isn't.
The OSI is the founder and DEFINER of the term "open source" so saying that it's open source without an OSI approved license is like saying your app's an approved Android app without it first being reviewed. Get it??
But it was done coincidentally with the discussions that ultimately led to the OSI and the OSD.
>> Bruce Perens has applied to register "open source" as a trademark and hold it through Software in the Public Interest. The trademark conditions will be known as the ``Open Source Definition'', essentially the same as the Debian Free Software Guidelines.
Bruce attempted to register a certification mark (a type of trademark), but the application lapsed in 1999 after OSI discovered that there was virtually zero chance of registering the term "open source" as a mark, as the term is too descriptive.
No. Even if you accept the Open Source Definition as the sole arbiter of what's open source, "approved by the OSI" is not one of its 10 criteria. It is possible for a licence to meet the OSD whether or not the OSI has approved it.
Bruce attempted to register a certification mark (a type of trademark), but the application lapsed in 1999 after OSI discovered that there was virtually zero chance of registering the term "open source" as a mark, as the term is too descriptive.
OSI has "OSI Certified" as a registered trademark (a certification mark).
> The OSI is the founder and DEFINER of the term "open source"
No it's not. It's some random group of people that usurped the term and tried to take control of the marketing of a larger movement that was already underway and would have happened with or without them.
Ok so they coined it but if they wanted to police who used the term they should have trademarked it and sued everyone who used it without their approval. Of course they wouldn't get very far with that strategy, but then they shouldn't expect to eat that cake.
I wasn't aware that the OSI was the only one who could declare something to be "OPEN SOURCE". Is there a certification fee to have my license / code blessed with the designation?
I don't see anything on that page with gives you, the OSI, the legal right to declare things as being opensource or not. You categorically stated it wasn't opensource. Had you stated that in your opinion it wasn't opensource it would be different.
Nope. I just dislike it when someone tries to claim control over a simple English words. They don't have a trademark on open source so they don't get the right to go around saying what is / isn't open source.
They made up the term and their definition is what most people associate with "open source". This is not a legal right, it's just "let's not redefine words because we don't like their common meaning".
> I brainstormed this with some Silicon Valley fans of Linux (including Larry Augustin of the Linux International board of directors) the day after my meeting with Netscape (Feb 5th). We kicked around and discarded several alternatives, and we came up with a replacement label we all liked: "open source". [0]
Also note, that the OSI didn't exist when they came up with this new label.
> Their OSD is what defines open source. You didn't define it. It wasn't defined at some party or demo-conf. It was defined by the OSI - they defined Open Source Software.
Isn't the OSD basically the DFSG? Therefore one could argue that it was actually defined by Debian, not the OSI.
You may be talking past another. I guess what GP was asking is whether OSI has a trademark, copyright, or something else for the term "open source"? The term "open source" has been generically used for much longer than OSI's existence.
Big difference between a "party" and a strategy session. So it wasn't literally defined at a party. And, even if it were, I guess it doesn't matter. The OSI owns the OSD which is what defines what Open Source is.
The process I underwent for The License Zero Reciprocal Public License last year, and the process described to me by participants affiliated with OSI during those discussions, did not match the process described on the page you linked at the time, especially its "What Will Happen" section. At least one participating member of the board seemed to be learning, as well.
Best I can tell, the process page was prepared by a former board member pushing to reform the process and make it transparent. It was and remains aspirational. But those aspirations aren't shared by remaining participants with sway.
The most straightforward summary of the process I received was that discussion proceeds on the mailing list until it reaches consensus, and then it's entirely within the board's discretion what it does or does not do. It was also written repeatedly that the board may not approve professionally drafted, novel, OSD-conformant licenses, for unspecified policy reasons.
Is it your companies official stance that they have the sole right to determine what is OPEN SOURCE code? From an outsider who reads this phrase in countless contexts, this feels like an incredibly naive and non-legally binding opinion
The OSI defined "Open Source" so they kinda get to put the rules to it. There is an Open Source Definition (OSD) which states what the license to the software can and cannot do. It's primarily about licensing at the OSI, not about open source itself. The definition clarifies what can be considered "open source" so organizations that need structure have something to follow.
As for apps, there's no approval process for an application - only the license applied. And if you use one of the 83 OSI-approved licenses, you can be guaranteed that your software falls under the Open Source Definition, stewarded by the OSI.
It's been a big help to me in both understanding what freedoms I have as a consumer of software, as well as providing me with thoroughly vetted, top-quality licenses to work with when I'm trying to give freedoms to the people who consume my software. OSI is incredibly useful, and have probably saved me needing to consult with a lawyer at least couple of times already. Now spread that benefit across an entire industry to get an idea the amount of value they provide!
I certainly learned some things today. I didn’t realise ‘open source’ had such a specific meaning, and I understand why it’s useful to establish the definition so there is no ambiguity.
Reading the replies to this thread is like watching hippies fight over the definition of free love.
Open source doesn’t mean anything unless we all agree on one definition, and while idealistic developers might reject the idea of central authorities to uphold the meaning of things now, they forget that it was idealistic developers just like them that realised an agreed definition was required and established the OSI 20 years ago to uphold it.
The OSI is not the man telling you what you can and can’t do - a shared and agreed definition of what open source is clearly benefits all of us, and if you just invent your own definition through ignorance or sheer bloody mindedness then you’re not legally in the wrong, but you could find yourself embarassed, exploited, or otherwise screwed through not understanding what the consensus definition is.
We are arguing over rather or not a body saying they haven't reviewed rather or not something fits a definition qualifies as not fitting that definition.
The answer is no, it does not, hence why OSI's statement is inaccurate.
The Open Source Definition is plenty ambiguous. It's not even internally consistent. Read the introduction, which sets us up for rules about license terms, and then criterion 2, which talks about source availability. What LICENSE says for the binary doesn't guarantee the distributor source.
That doesn't mean OSD was bunk or busted. It means we've preserved it for historical relevance, not operative function. Else we'd've revised a great deal more in 20 years.
Instead, in discussion of new license submissions, we routinely see readings of OSD criteria that would exclude the very set of contemporaneous, popular licenses the original Debian Free Software Definition was meant to generalize. For example, that criterion 6 prohibits discrimination against proprietary development as a field of endeavor. OSD isn't a consensus, exactly because it invites so many such readings. There's consensus only insofar as interest groups agree to disagree in OSD terms, as a framework. Some don't. Notably FSF, with its own "definition".
The trouble with open source is that it's a movement, a community idea, not an entry in any formal lexicon, not a fixed point. License terms are only incidental to that movement, that community idea. A zeitgeist and a name. And there's nothing particularly legal about OSD criteria, apart from the expectation they'll be implemented in the legal medium of public license terms. Legal's no magic font of rigor here.
As I'm led to believe, "Free Love" never suffered such discipline as OSI claims now. Free Love was something people were into, stood for, practiced. There was never any organization proffering a definition of Free Love as definitive, official in some sense, and telling folks their particular love didn't count, wasn't free enough. "Free Love" meant something because of how it was used and understood, variously, not how it was defined. It was always contested, and contestable.
Pretending that the OSD, or more accurately OSI approval, represents consensus for new proposals clearly benefits only those who like the particular status quo that a select subset wish to preserve by clout right now. Circa 2002, OSI was approving plenty of licenses in the vein of Mongo's new terms, to welcome smaller businesses challenging more powerful incumbents on behalf of the open approach. Notably RPL and QFPL and Watcom. The permissive-industrial complex hastens to elide or deprecate those approvals now. Even though today very arguably wasn't reachable without accepting strong reciprocal licenses for dual licensors, as a waystation.
I don't think that an appeal to authority is a very good way to make this argument. It's the blatant restriction to the field of endeavor which makes this license quite obviously not open source, because there's nothing open about something which certain people are not allowed to use.
But the OSD is maintained by the OSI, so an appeal to "authority" is a great way to make this argument. The OSI gets to decide what fits their OSD (which you quote) so it's really a non-issue.
If you later approve the license, then under your company's own definition of "open source" that means it was always open source, even now, so saying they are not open source when you admit you have not reviewed the license fully yet, is inaccurate, and could very well lead your company into legal liability if your statement turns out to be untrue and mongodb sues for slander.
furthermore: If you later deny the license, that may mean it was always not open source. May.
Your board is not the gatekeeper to the open source community, you are not the controller, authority, or president of the open source community, and the open source community as a whole is the only body that can decide what is "Open Source"
While you're reviewing the license, I'd be interested in the OSI's opinion as to whether or not the SSPL retains compatibility with GPL software in light of the striking of the relevant paragraph in section 13—and what the implications would be of adding it back in.
Your opinion isn't the only one out there. I recognize the OSI as the authority on the term open source.
On a more practical level: who do you consider be the authority? If the answer is 'nobody' (except yourself) then that makes the term essentially meaningless because there is no standardization, which means that one should stop using that term.
MongoDB recognizes OSI as an authority as well, which is why they submitted their license to OSI for approval. Which led us to this moment, where OSI has not (/yet) granted that approval, and that apparently raised gp's hackles for some reason.
MongoDB recognizes that OSI approval is a nice thing to have as a selling point. I very much doubt that they accept the OSI as an authority that can make binding rules and regulations about who gets to call their software "open source".
I was addressing OP's suggestion that RMS is the authority on "Open Source" (which was the question further up the thread). He'd rather have you use/contribute (to) Free software instead.
Yes, I understood that, I assume the OP meant that he is an authority on "open-source" in that "free software" was the original "open-source" and thus "open-source" has RMS a lot to thank for. Otherwise I agree.
It might be the original "open source" but it ISN'T open source, per the definition. Open Source was coined for software LONG AFTER the FSF had declared what free software meant.
Going back and saying "Well, RMS might have MEANT open source, so it's actually the original open source" is very subjective and not historically accurate.
> Open Source was coined for software LONG AFTER the FSF had declared what free software meant
I know, you COMPLETELY misunderstood my comment.
> Going back and saying "Well, RMS might have MEANT open source, so it's actually the original open source"
I don't think he meant open-source and I am not saying he did, as free software defines greater freedoms. I am not a big fan of open-source myself, much prefer free software.
What I am actually trying to say, is that "free-software" was the original way to share code and work on it collaboratively for the commons, ie the thing open-source got inspired by.
What I am saying, is that in certain sense, you could say that Ken Thompson has a grandfatherly hand in Linux, despite him technically not. It's a spiritual hand, if you will.
RMS has an ideal: All software should be free and open.
This doesn't work for businesses that need to profit from what they do. Keeping things proprietary, while benefiting from source-available software is impossible if a company has to release their source. Competition goes out the window.
So while RMS has a nice ideal, it doesn't generally apply.
> " Keeping things proprietary, while benefiting from source-available software is impossible"
That's a tragedy of the commons, not something any company is entitled to (BSD-style licenses excepted). Enjoying the benefits of an ecosystem while not contributing to it is not a thing to laud.
> So while RMS has a nice ideal, it doesn't generally apply.
...and here we are, with a MongoDB pulling a bait-and-switch on licensing because they want to have their cake and eat it. You shouldn't expect to only get the kudos (and higher adoption rate) that result from your open-source license and not run the risk of someone (possibly a competitor) forking your code. That is the price of admission into the open-source world.
Dictionaries reflect common usage and shared understanding, they're not some infallible source. If the technology community started using the term "open source" in a different way, the dictionary would have to be updated to reflect the new meaning.
The definitions in a dictionary are for general purposes and not used, necessarily, in legal battles. There are legal definitions for things like Intellectual Property, Copyrights, Patents, and Trademarks. These definitions are what will be used when it comes to determining, legally, what open source is - not some wordsmith.
Noah Webster did use a strongly prescriptive approach when he wrote his dictionary. His decision to use alternate or simplified spellings of some words is still seen today as the differences between American English and British English. Linguistic prescription - the idea that there is a single "correct" language and other uses of language are somehow inferior or improper - was used to intentionally to give American English it's own identity.
Fortunately, most modern dictionaries recognize that languages evolve, using a descriptive approach, updating definitions when needed to reflect how words are actually used.
So by me saying that the term might be interpreted differently by different people - since it can't be owned by anyone now that it's in wide use (and hence implying there's different opinions out there) you assume that I fail to see there's a multitude of different opinions on the matter? That's exactly the point I was making.
Only if you're completely ignoring the context, which is MongoDB asked OSI to approve their license as "Open Source" - OSI isn't in a position to do so immediately, and so in OSI's estimation, MongoDB isn't "Open Source"
As OSI hasn't yet reviewed the license, perhaps it would have been better for the OSI VP to explain that "MongoDB may not meet the OSI definition of Open Source" than to announce (in CAPITALS, no less) that "MongoDB...IS NOT OPEN SOURCE".
> "MongoDB may not meet the OSI definition of Open Source"
That's just euphemism for "MongoDB is not (certified) Open source". It either is, or isn't; and presently it isn't, for reasons that were entirely under MongoDB's control.
If it doesn't fit the OSD (https://opensource.org/osd) it IS NOT OPEN SOURCE. The license has not been reviewed by the OSI, and there isn't any "Approved until shown otherwise" clause to refer to. So, in the OSI's eyes (and really anyone who knows what open source actually is) it's NOT OPEN SOURCE anymore.
Well, that presupposes that the OSD is the One True Definition of the term "Open Source"; although the OSD is widely accepted and respected, that's a rather bold claim over an English phrase.
> it's NOT OPEN SOURCE anymore
That claim doesn't seem justified at this point. It would be more accurate to say that it is not currently CERTIFIED BY THE OSI as being Open Source -- because the OSI has not yet reviewed the new license. Maybe it will turn out that it is Open Source (as per the OSD), maybe not. Until the license is properly reviewed, we simply don't know.
The only people who interpret the term open source differently from the OSI definition are either wrong or deliberately trying to sow discontent in the open source community.
In a funny way, I actually don't think ownership of the term, or even who gets to decide that, is what really matters. Mongo can release their software under a license they term "open source", or "special mongo license", or "license X" -- they're under no obligation to use any commonly-accepted licenses or terms. They are certainly free to call themselves "open source" under any new license, and make their arguments as to why they believe that term applies.
However, what really matters here is whether, if they choose to do that, developers would still be willing to freely contribute to Mongo's code base, and whether companies who use open source software will continue to use their product. Because _that's_ the reason Mongo cares about being "open source". If most developers and organizations recognize the OSI, with their license approval process, as the arbiters of what constitutes an open source license, then that's the reason the OSI's opinion here really counts. Not because they have some divine right to that term, but simply because if they say "after review, we don't consider this project to be open source by our definition of open source", developers and organizations may hesitate to contribute to, or use, this project.
The OSI owns the definition, yes. You are incorrect.
See https://opensource.org/osd which is what DEFINES open source. The term has been around for 20 years. Your lack of understanding the history doesn't make you any kind of an expert.
No, OSI doesn't own the definition and doesn't get to define open source. Some people agree with that definition, some don't. Nobody has to though. You can't really own what other people think, you can only try to agree on some definition during interaction. No need to pretend there is some universal truth that they just don't know about. It's an agreement, not truth.
And OSI might become irrelevant anyway if it doesn't change in light of recently emerged licenses with more restrictions and doesn't certify them in some way. People will just stick to a handful of popular known licenses and call them open source.
Yes, they do! They are the ones that put together the OSD (https://opensource.org/osd) which they derived from the DGSL. No one else has defined open source, not even Richard M. Stallman. His definition is for "Free Software", not "Open Source".
So when it comes to who owns the definition, the definitive answer is the OSI. Anything else is just subjective opinions.
You must not work. Because businesses that do REAL BUSINESS and use Open Source are happy that there is the OSD and approved OSI licenses. That way, we can make real, LEGAL decisions. For individual developers, they might have a different idea of what the definition is, but the actual reference to what defines it is at: https://opensource.org/osd
Reading that will clarify what open source is and isn't. Anything else is just "free software" and should hunt down the FSF for licenses and such. RMS has a very different opinion on software that DOES NOT WORK for large corporations.
I think what I'm seeing over and over in this thread is people talking past each other because the grandparent shouldn't have assumed we were all working in the same context.
I agree, in the legal context of business decisions, OSI has a very specific claim to the term 'open source' and declaring that mongoDB "IS NOT OPEN SOURCE" is a warning directed towards people making business judgements around legal risk.
To everyone else, we use the term 'open source' because we heard someone else say it, and when we write software we say 'oh it will be open source' without getting into the nitty gritty of what license it will use and whether that's OSI approved.
> in the legal context of business decisions, OSI has a very specific claim
But it doesn't. In the legal context of business decisions conformance to an OSI definition of "Open Source" means exactly nothing and OSI-certified "Open Source" even less than nothing. It doesn't help you with anything and doesn't protect you from anything.
Honest question. If I write some code and release it on Github with an MIT license, do I need permission from OSI to call my project "Open Source"? Is there a legal requirement? I am confused.
Fair question :-) And the answer is no, you would not need OSI's permission to call your project open source -- because you'd be using the MIT license which has been reviewed and approved by the OSI.
You can find the list of approved licenses, along with information about the review and approval process, over at https://opensource.org/licenses
You can call your software open source no matter what license you use. People may harrass you, but there is no legal restriction on the use of the term and OSI cannot sue you.
You don't need anyone's permission to call anything "open source". There's certainly no legal requirement.
Note, however, if this language starts making its way into contracts, and you're calling something "open source" that isn't actually open source by any standard meanings of the term, then you could be in trouble. But releasing something under a common open source license is prima facie open source, so no problems there.
> There also is no guarantee that the license will be found to obey the Open Source Definition, and therefore no guarantee that it will be approved.
This shouldn't be surprising -- it blatantly violates the spirit of section 9 (if not the actual wording). I would be quite shocked if the OSI decides the new license is "open source".
> 9. License Must Not Restrict Other Software. The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
I wonder what RMS / the FSF have to say about it...
>> MongoDB is under a non-approved license and therefore IS NOT OPEN SOURCE
Hey, that's not true - neither yourself nor OSI or anyone else gets to decide that. If the nice folks at MongoDB continue to release their source code, then it's open source. End of story.
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]?
None of OSI's Open Source licenses (including AGPL) protect creators financial interest in the cloud first world. Period.
I want to issue "View and Internal Use License" for my work. Anyone can view the source code, modify, and use the software for their own benefit as they see fit. Under no circumstances can anyone sell/re-distribute/host the paid version of software or any derivative thereof. Why can't OSI create such a license?
I understand the spirit of OSI is to foster more usage of open source software. I admire it. But probably a LOT of open source software is not getting built in the world because it's not possible for everyone to spend few months/years of their prime without any financial outcome (not even a possibility of it).
I'm a developer who spent 3 FULL days reading up licenses for my indie project [1] that I aim to make some money with. Not even a single license was adequate to protect me from large teams/companies if the software were to become popular. I resorted to only open sourcing a required critical library [2].
The license you describe, while definitely useful, is not open source by any meaningful definition of the concept. I don't mean "not OSI open source", but "not open source as the term has evolved". Similar licenses have been tried (see Microsoft's Shared Source Initiative) and you can definitely devise one yourself and no-one can stop you.
The "world" won't let you call your license open source for good reason: it's not open source.
The whole point of open source is that OSS code can be used (and modified) for whatever use anyone wants. Copy-left compels you to share your modifications, but does not limit you from using the software however you please.
> The "world" won't let you call your license open source for good reason
What is that good reason?
Is prohibiting commercialisation of my work not in the spirit of open source? How is my "View and Internal Use License" bad for the open source ecosystem?
Do you not see any problem with that? Companies who are good at commercialisation gets all the dough for work created by small group of inventors. Is protecting inventors interest not important? Isn't this negatively affecting the ecosystem where there's less motivation for inventors to create open source software in the first place?
> it's not open source because it forbids redistribution of the source.
This can be solved easily. The "View and Internal Use License" can allow redistribution under the same license (verbatim).
I'm not going to debate open source with you, because as you can imagine this is a topic that's been debated for decades, and as any debate that mixes philosophical and technical issues, it's definitely neither easy nor clear cut.
Open source is mostly about user rights (making things more confusing, a user is sometimes also a developer!). By restricting the users' right to resell or redistribute the source code of your software, you are effectively making it not open source. If you think an open source license is not in your best interest because of these rights, it'd be totally understandable if you decide not to use one.
> This can be solved easily. The "View and Internal Use License" can allow redistribution under the same license (verbatim).
I think you'll find once you add all the necessary provisions for adding users rights, you'll end up with an open source license :) I'd be wary of saying "this can be solved easily": if you follow any kind of debate about software licenses, proprietary or otherwise, you'll see there's nothing easy about them. Any license that is more complex than "do whatever you want with this" is probably not easy.
> By restricting the users' right to resell or redistribute the source code of your software, you are effectively making it not open source.
Then the discussion Open Source ecosystem needs to have is whether "protecting users' right to resell" is net positive or net negative for the ecosystem. And answer could go either ways but that dialogue needs to happen.
Last major update amongst any of the popular OSS license was in 2007 to AGPL. It's been 11 years and SaaS/Cloud world has changed a lot in this time. Maybe, just maybe, it's time to review and see if we need an additional license that's net positive for the ecosystem.
Just accepting current textbook definitions of Open Source and abiding by it all our life seems too pedantic.
It's not the "current textbook definition" but a living consensus. This "dialogue" you want begun decades ago and is still ongoing. I'm not sure why you think otherwise. (If you want an even more difficult debate, there's the "open source" vs "free/libre software" thing: https://www.gnu.org/philosophy/open-source-misses-the-point....)
> Then the discussion Open Source ecosystem needs to have is whether "protecting users' right to resell" is net positive
Well, reselling is not the most important aspect; it's a side-effect of unrestricted users' rights. If you restrict users' rights (e.g. you forbid reselling), open source becomes less appealing and not particularly different to Microsoft's Shared Source and similar proprietary-but-you-can-see-the-source licenses.
By the way, "net positive" is a tricky concept. Open source is in my opinion a "net positive", but it involves some trade-offs. Proprietary licenses like the one you seem to favor also have trade-offs.
> it's time to review and see if we need an additional license that's net positive for the ecosystem.
Which ecosystem is that?
To be honest, it seems to me you don't want an open source license. And that's fine. Not sure why you want open source to change its meaning to what you propose (which isn't new either), instead of simply accepting the license you want/need is not open source.
It would be closer to "source available". See eg tarsnap.
> Is prohibiting commercialisation of my work not in the spirit of open source?
Roughly (IMNHO) there's Stallman/gnu style Free software, which is about user freedoms (freedom to run the software being freedom zero). And the Raymond/cathedral vs bazaar "open source", which is about developer freedom - the freedom to learn from and build (in also a business sense) on other software (mit/bsd/apache etc).
The distinction isn't absolute, a gnu "user" is certainly a developer too - but "open source" isn't as concerned with user freedom - especially freedom zero.
With drm, signed bootloaders and trusted computing - it's easy to see a world where even access to source code and compiler tool chain doesn't guarantee the freedom to run a) binary software from a vendor, nor b) software binaries you make yourself.
So gnu/free software isn't primarily about preventing commercialization (see eg: walnut creek software and their CD rom/floppy shipping business) - it's about maintaining user freedom.
And many believe the only real way to legally protect end user freedoms is through means like gpl/AGPL.
In a sense gnu is pessimistic free software (what if I can't (legally) access a c compiler and kernel header files - how can I even build a new printer driver then?) - open source is more libertarian/free market optimistic: go ahead build a firewall appliance from this distribution and lock your customers out - there's plenty other folk that will keep sharing and caring. And if you develop a cool, high performance userspace network stack we'd love for you to share - but do as you please)
Neither is about preventing commercialization - both are about securing access and openness. Now, they do work against certain types of legal mechanisms that are associated with commercialization, like patents and copyright.
Lastly,in a world with copyright, "source available" can be very dangerous to developers (this include text books with unclear licenses for code examples). What happens when I copy your btree implementation? You did show it to me. Was I supposed to forget about it?).
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.
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.
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.
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.
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.
It's their code so (under current law) they can license it however they want. I see some potential issues, though.
> "Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate."
I don't see how to reconcile this with the new section 13, which seems to say exactly the opposite. What does this section mean, now that section 13 was completely changed?
> it has now submitted the SSPL for approval from the Open Source Initiative
IANAL but I don't see how it satisfies part 9 of the OSI Definition, or the DFSG. As DannyBee already mentioned, it's also incompatible with other existing open-source licenses. Why do they want to continue calling it "open source"? It sounds like they really just want to be a proprietary database.
> For virtually all regular users who are currently using the community server, nothing changes because the changes to the license don’t apply to them.
Really? It's written in a way that sounds like it captures all users under the same umbrella as resellers. If I wrote a data analysis web app that happened to use MongoDB (as one of my previous employers did), isn't that a case of adding "user interfaces" (and "storage software and hosting software") for it, meaning I'd need to provide source code for "all such that a user could run an instance of the service using the Service Source Code you make available"?
I can't find any license pricing info on the MongoDB webpage, but some googling turned up a whitepaper that puts MongoDB licensing at around $11,000 per server per year. That basically means MongoDB's own "cloud" services are the only game in town. ("No, Mr Bond, I expect you to die.")
That means there's a single provider of this API, and you can't afford to run your own server, so it's essentially cloud-only, and it might not be legally compatible with other open-source software you want to use anyway. That's a whole lot of risk you're asking me to take on. Is MongoDB so much better than any free database, for any new users, that it's worth this risk?
> IANAL but I don't see how it satisfies part 9 of the OSI Definition, or the DFSG. As DannyBee already mentioned, it's also incompatible with other existing open-source licenses. Why do they want to continue calling it "open source"? It sounds like they really just want to be a proprietary database.
They want to charge money and have control as a proprietary database. But they want to keep a label "open source" purely for marketing purposes.
I'm embarrassed by the lack of comprehension people have for the idea of the OSI saying something isn't open source. The OSI has been around for a long time, has a consistent track record of helping organize FOSS licenses and create a framework/lexicon for this very purpose. They absolutely have the right to say if something is open source or not, according to their rules, just like anyone here gets to make their opinion heard on something. "Appeals to authority" make sense when the authority is credible, and shortcuts having to explain the four freedoms, etc.
---
To the article: It sounds like the SSPL will eventually be OSI-OSS, but I wonder if they couldn't have worked with GNU to create a new version of the AGPL. Granted, GNU might take exception to the idea of "oka you don't have to share the code, you just have to pay us" portion.
I think it's more about the tone and the caps lock, than the exact words, although you shouldn't be embarrassed if some people disagree and think the phrase has been generalized. If anything, I think it might be embarrassing how many "defenders" jumped in and prolonged this drama, instead of just downvoting and moving on with their day. How's this for a conundrum: I support the OSI being able to claim it isn't "open source" according to them, but I think the top-level post by the VP was unprofessional and rightly called out. (I have not commented elsewhere in this thread.)
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?
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
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.
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.
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.
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 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?
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.
My reading of the below essentially says: you cannot offer MongoDB as a (closed) SaaS (without purchasing a license). There will be debate though about how far-reaching this clause is. Note that MongoDB as the copyright holder is giving themselves a different license for running Atlas. I don't know if this is the only change to the license, but the below is certainly not part of the AGPL:
13. Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version.
"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.
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.
The prohibition on providing the software as a service appears to conflict with, or at least be trivially bypassed by, section 9 which states that to run the software you don't have to accept the terms of the license. Section 9 conforms with the law as written: running the software, and making the copies needed to run it, are explicitly not an infringement of copyright (USC Title 17 section 117(a)(1) [cornell.edu]). If I don't have to accept the license to do something, I'm not bound by it's terms merely because I do that something.
As an open source dev, I think the new SSPL license of @MongoDB is interesting. SaaS is the new black nowadays, I have seen too many companies burnt down trying to support their OSS licensing with SaaS taking all the benefit. SSPL can help #OpenSource.
I also think that SSPL can be very helpful if you want to open source your SaaS. Most of the startups that I consult with are not interested in open sourcing their actual SaaS software since they fear being ripped off.
So, what happens is that they end up not taking the benefit of open source. With SSPL these SaaS companies will be able to open source their SaaS is software to manage SaaS — without the fear of being misused by competition.
If the competition just takes their free software and makes money with SaaS that hurts them instead of helping them since you can't make sure that other SaaS players will actually contribute back to the software.
With SSPL, we get a safety net — companies either won't use it as a SaaS, will pay to use it as a SaaS i.e. they'll help pay for open source software support which is a very good business model and if not that, then they'll have to open source their SaaS as well.
As a non-lawyer developer, it feels like GPL. GPL code that you fork should remain GPL. Similarly, if SSPL code you use as a SaaS then you should keep your SaaS as SSPL and open source it as well.
If SaaS vendors haven't opened their software that uses Mongo under AGPL then I would assume that the additional software (which would count as another "part of the aggregate" according to AGPL), then it must have been substantial. In that case, how does one determine if one is "offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version"?
I assume that an online game that uses Mongo to store player data clearly does not derive its value mostly from the database, but is the value of a PaaS built on Mongo, with an elaborate UI and management services derived primarily from the value of Mongo or not? Is the value of an online recipe management service? In both cases I can see compelling arguments in either direction.
One could argue that if the value derived primarily from the DB, then very little software would need to be added and open sourcing it would not be an issue. That vendors don't open source their software shows that they believe its value does not come primarily from Mongo, and so they would be able to continue using it under the new license, defeating Mongo's purpose.
This question isn't directly associated with MongoDB, please forgive my lack of OSS license expertise.
I was curious if exceptions were allowed under licenses like these. For example, if a company releases a GPL licensed product, (or SSPL etc) and wishes to create another product/service that they don't wish to open source, but it's based on the GPL/SSPL codebase. Could they make exceptions or separate license agreements to go around their own license choice? Would it be different if it were a third party they would like to give this exception to?
In similar regard, would MongoDB have to prove that they are paying full licenses/Enterprise agreements to themselves to be able to run Atlas (their own cloud offering) and not open source Atlas? Or is there a self exclusion allowed etc? Or would they just sell themselves the licenses for $0.01 cent to get around the requirement?
Truly interested in this question.
Edit - and to clarify, not if the exception is stated directly in the license like a new modified MIT etc, but inherent to the existing popular OSS licenses.
You can allow the general public to use your code under the SSPL, give somebody else the same code under the GPL, give a proprietary licence to somebody else who paid you money, and use it yourself in a way that would violate any of those licences. Licences you give out can't really restrict you, since you own the copyright of the code.
The piece in the puzzle that allows MongoDB Inc. to act like that is the Contributor Agreement [1] which makes any contributor assign copyright of contributions to MongoDB Inc. This way MongoDB Inc. is has all rights on the source code and can licence it to anyone under any licence.
If I own a block of code, I can release it under as many licenses as I like, even if those licenses would totally conflict, and then each one of my users will need to track which license they received it under and adhere to those terms (only). So yes, I can give Users 1, 4, and 5 a copy under the GPL, and then users 2 and 3 a copy under some commercial license, user 6 under some GPL incompatible copyleft license, no problem.
The key is where you say "wishes to create another product/service that they don't wish to open source, but it's based on the GPL/SSPL codebase". You're not creating it based on the GPL codebase, you're creating it on the codebase you own. The fact you've previously licensed it under X, Y or Z licenses is irrelevant; you can always release it again, in whole or in part, with whatever license you like. (But of course, whatever you released under the GPL is still out there, under the GPL; there's no take backs!) And you can also, of course, use it yourself however you like.
The key is ownership. If you own the copyright on the code, you're fine. If you don't, you must adhere strictly to the license which the actual owners granted you. To the extent that MongoDB (the company) owns the copyright on all the code, they're free to use it how they like, and release it as often as they like under whatever licenses they like.
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.
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.
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.
IIRC MySQL had a bit similar troubles with GPL license. They disliked the fact that some companies shipped closed source software which in practice required MySQL, but instead of getting the paid license, they relied on the open source version.
Google revealed one relevant article:
According to C|net their vice president of marketing said in 2002:
"There were people misusing the GPL, using our server tightly coupled with their applications, claiming the GPL didn't apply because the client libraries weren't under the GPL, they were under the LGPL,"
[1]
According to the article, MySQL decided to sort out this issue by changing the license of the client libraries from LGPL to GPL.
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.
It is still unclear to me how the release of any "Service Source Code" is scoped. The license states:
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License
Would greatly appreciate it if someone could give an example of a MongoDB service company and what parts of their proprietary code they would have to release if they opted not to buy a commercial license .
> “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...
It's as broad as it can be to make it essentially impossible to comply with and force you to use the commercial license. You can't release the Linux source under SSPL, but the OS would almost certainly qualify under this clause (but IANAL). In the definitions it seems to exclude the kernel and "System Libraries" but only if unmodified, it's still a but of a minefield.
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?
"MongoDB is a bit miffed that some cloud providers — especially in Asia — are taking its open-source code and offering a hosted commercial version of its database to their users without playing by the open-source rules. To combat this, MongoDB today announced it has issued a new software license, the Server Side Public License (SSPL), that will apply to all new releases of its MongoDB Community Server, as well as all patch fixes for prior versions."
You assume this "Intellectual Property" or "Copyright" thing exists in China. After working for a Chinese company, the concepts don't have an analog in their culture. Actually the concept of licensure in general doesn't have a good analog. They see open source as free and sort of brush off the strings that are attached.
(this btw, should not be interpreted as bad mouthing them; I'm merely pointing out a communication problem between two cultures).
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.
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)
> 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.
(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.
Likely a move since the purchase of mLab to eliminate competition in the services space. Seems a lot like the recent changes with the direction of Redis.
Hopefully this spurs some movement in supporting open database communities better. PostgreSQL and RethinkDB being two that come to the front of my mind.
> Making the functionality of the Program or modified version available to third parties as a service includes […], or offering a service that accomplishes for users the primary purpose of the Software or modified version.
Would this apply to independent implementations compatible with MongoDB?
IMHO a better move for them would have been to clear up the legal minefield that comes with AGPL and move to a more business friendly license like the Apache 2.0 or MIT license. These licenses are well understood and don't cripple your users in any way.
I don't get why any business would want to scare their new users with a license like the AGPL that I would argue is explicitly designed to create legal uncertainty like that and popular with companies like Mongo primarily for that reason (as opposed to some strong freedom related moral arguments). Inventing your own license because the AGPL is giving your users to much freedom sounds rather desperate (not to mention misguided).
Changing the license to Apache 2.0 might actually make them much more attractive as an acquisition target for any of the big tech companies out there looking to add something like mongo to their portfolio. I'd argue AGPL is actually an obstacle for most of the bigger companies out there that have existing business relations with their customers based on more business friendly licenses.
It would also enable lots of people to experiment with using mongo without legal worries and thus enable them to refocus their company around actually creating value for their paying customers without alienating the vast majority of non paying users with complicated licensing options.
Companies like Elastic (which recently did their IPO) are having plenty of success with using the Apache 2.0 license without compromising on commercial success. Their developer ecosystem includes lots of outsiders in the apache community, the academic community, and users. The reason they are doing pretty OK is that they have a decent monetization strategy that involves delivering actual value to their customers: stuff their users want and are willing to pay for. Stuff like proprietary add-ons (e.g. machine learning) on top of what they ship for free, good support, training, cloud based hosting, consulting, etc. We use their hosted Elastic cloud and I'd argue it is pretty good value.
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.
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 think long term model of Company opensourcing primary product will fail outside of projects that are targeting niche too small for Azure/AWS/GCP to monetize.
TL;DR: while vmbrasseur of OSI does say "what's done is done" in comments here, I think the OSI shouldn't accept the proposal as submitted, and should demand that licenses submitted them to have gone through a prior public drafting process. This is particularly important for licenses whose stated goal is to make fundamental changes to how copyleft works. GPLv3 and (even better) copyleft-next made this the standard of how new license drafts are done, and we should follow that standard.
My friend, the "what's done is done" was purely in reference to the fact that the license was submitted for approval belatedly (IMO). My statement in no way implied whether the license itself would be approved as it stands.
Now that the license has been submitted, folks can now analyse and discuss it, openly. Any decision on the license will spring from those discussions and the related actions (should any be needed) that MongoDB takes based on the feedback they receive.
The proper place for that feedback is on the discussion thread on the review mailing list. Statements on blogs and comments on Hacker News are good for helping to frame that feedback, but aren't well placed to be included in a cohesive conversation.
I guess next one that will do that - if this works- will be elasticsearch and they will then have to fight amazon on this.
The risk being that if someone does a better job than MongoDB at creating features for mongoDB they might loose their product as well playing that card.
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.